Buzz Desktop ignores a managed agent's configured mcp_command — custom MCP servers never attach

**Repo:** block/buzz · **App version:** 0.5.5 · **Platform:** macOS
**Severity:** High — blocks every managed agent from using any MCP other than the bundled `buzz-dev-mcp`.

## Summary
A managed agent's configured MCP command (`managed-agents.json` → entry `mcp_command`) is **never forwarded** to `buzz-acp`. On every agent start the launcher spawns `buzz-acp` with the bundled sidecar:

```
mcp_cmd=/Applications/Buzz.app/Contents/MacOS/buzz-dev-mcp
```

so agents only ever get the bundled `buzz-dev-mcp` tools and can never attach a custom stdio MCP. Setting the env override `env_vars.BUZZ_ACP_MCP_COMMAND` on the agent does **not** help either (see root cause).

## Impact
Every managed agent is limited to the bundled `buzz-dev-mcp`, so the per-agent `mcp_command` field has no effect. Any deployment that relies on a custom MCP (e.g. a multiplexer that adds extra tool servers) cannot attach it. Observed across many agent starts across all agents: `mcp_cmd` is always the bundled `buzz-dev-mcp`, never the configured value.

## Reproduction
1. In `~/Library/Application Support/xyz.block.buzz.app/agents/managed-agents.json`, set an agent entry's `mcp_command` to an absolute path to any custom stdio MCP, e.g. `/opt/example/my-mcp`.
2. Fully quit and relaunch Buzz Desktop (not just restart the agent).
3. Inspect the agent's acp log under `~/Library/Application Support/xyz.block.buzz.app/agents/logs/`.

**Expected:** `buzz-acp starting: … mcp_cmd=/opt/example/my-mcp …` and the MCP handshake reports the custom server (`server_info name` = the custom server's name).
**Actual:** `buzz-acp starting: … mcp_cmd=/Applications/Buzz.app/Contents/MacOS/buzz-dev-mcp …` and `serve_inner … server_info: Implementation { name: "buzz-dev-mcp", … }`.

Also reproducible by setting only `env_vars.BUZZ_ACP_MCP_COMMAND=/opt/example/my-mcp` (no `mcp_command`) and relaunching — the env value is still overridden by the launcher's explicit flag.

## Root cause
- `buzz-acp --mcp-command` is `[env: BUZZ_ACP_MCP_COMMAND] [default: ""]` (confirmed via `buzz-acp --help`).
- The desktop launcher spawns `buzz-acp` with an **explicit** `--mcp-command ` (it resolves the bundled Tauri sidecar `binaries/buzz-dev-mcp`), rather than forwarding the per-agent `mcp_command` from the managed-agent record.
- Because an explicit clap CLI flag wins over the env var, even setting `env_vars.BUZZ_ACP_MCP_COMMAND` on the agent cannot override it. So neither the config field nor the env override takes effect.

## Suggested fix (acp-spawn path of the desktop launcher / Tauri backend)
When building the `buzz-acp` argv for a managed agent, use the agent's configured `mcp_command` when non-empty, falling back to the bundled sidecar only when it is empty:

```rust
// pseudo
let mcp_cmd = if !agent.mcp_command.trim().is_empty() {
agent.mcp_command.clone() // honor per-agent override (absolute path)
} else {
bundled_sidecar_path("buzz-dev-mcp") // current default
};
cmd.arg("--mcp-command").arg(&mcp_cmd);
```

Equivalently: pass the configured `mcp_command` as the flag when set, OR stop passing an explicit `--mcp-command` when the agent supplies `BUZZ_ACP_MCP_COMMAND` so the env override can win. The launcher already forwards agent `env_vars` to the child process (other custom env vars set on an agent do reach the MCP), so the env plumbing works — only the explicit flag needs to defer to config.

## Why this is the right shape (no acp change needed)
`buzz-acp` intentionally accepts a **single** `--mcp-command`. The supported pattern for "bundled dev tools + extra MCPs" is a stdio **multiplexer** that itself spawns `buzz-dev-mcp` plus the extra servers behind one stdio server. That pattern works today when the multiplexer is driven directly — the only missing piece is the launcher honoring `mcp_command` so the multiplexer becomes the agent's attached server. Once it does, agents keep all bundled dev tools AND gain the extra tools, with no acp or protocol change.

## Workaround until fixed
None from config/env on the current build. Agents can still invoke a custom MCP indirectly by launching it as a subprocess from within a `shell` tool call, but its tools will not appear in the attached tool surface until the launcher fix ships.

Start at the desktop launcher's acp-spawn path and the managed-agent record that provides mcp_command; reproduce with managed-agents.json and inspect the acp log under agents/logs. Done means a non-empty configured command reaches buzz-acp, while an empty value still uses the bundled buzz-dev-mcp and the environment override is not incorrectly masked.

Written by the indexing model from the issue text.