buzz-acp: mcp_command / BUZZ_ACP_MCP_COMMAND is never wired for runtime=claude (only runtime=goose)

Related to #2899, but a step earlier: per-agent `mcp_command` in `managed-agents.json` (and its
`BUZZ_ACP_MCP_COMMAND` env-var equivalent) has no effect at all for agents running with
`runtime: claude` — only agents running `runtime: goose` pick it up.

**Repro**

1. Set `mcp_command` on a `runtime: claude` agent record in `managed-agents.json` to a working
stdio MCP server command (confirmed working standalone via manual stdio handshake).
2. Start/restart the agent.
3. Inspect the live process env (`ps`/`/proc`/`launchctl`, etc.) — `BUZZ_ACP_MCP_COMMAND` is empty
regardless of what's in the JSON.
4. The MCP server is never spawned; the agent has no access to its tools.

Confirmed by inspecting the full `managed-agents.json` field schema for several `runtime: claude`
agent records — `mcp_command` is present and non-empty in the JSON but has no corresponding effect
on the running process.

**Impact**

Any deployment with agents on `runtime: claude` (which appears to be the default/common case, not
an edge case) cannot use per-agent MCP servers via Buzz's own config at all today. The only current
workaround is a project-scoped `.mcp.json` in the agent's working directory (which Claude Code
auto-loads independent of Buzz), but that requires each agent to have its own working directory —
which `managed-agents.json` also has no field for (no `cwd`/`working_dir` key on the agent record).

**Ask**

Wire `mcp_command` / `BUZZ_ACP_MCP_COMMAND` through for `runtime: claude` agents the same way it
already works for `runtime: goose`, so this doesn't require an out-of-band `.mcp.json` /
`agent_command_override` workaround. Once that's fixed, #2899's "more than one server" ask becomes
directly relevant for `runtime: claude` too.

Happy to share the specific `managed-agents.json` field dump and process-env check that surfaced
this if useful for repro.