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

[natewerkz]

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.