buzz-acp: add structured MCP server configuration

[wolfyy970]

Summary

This gives Buzz one versioned MCP launch document instead of one opaque command per agent. buzz-acp accepts multiple named stdio servers, preserves their order, arguments and environment, and sends the same list through every ACP session. The existing BUZZ_ACP_MCP_COMMAND path remains the first compatibility input.

#4271 can add HTTP to the same document. Desktop and Project Connections can resolve approved tools into it without adding another runtime format.

Boundary

This document is resolved launch input. Personas, templates and Projects remain authoring state and are not passed directly to a runtime.

The adapter still inherits the harness environment, so this is explicit configuration rather than process isolation. On Unix, config files must be absolute, regular, owner-owned and owner-only. MCP values are structurally redacted from logs, observer events, diagnostics and returned adapter errors without changing the values sent to the agent.

Validation

• cargo test -p buzz-core -p buzz-acp -p buzz-agent --no-fail-fast
• cargo clippy -p buzz-core -p buzz-acp -p buzz-agent --all-targets -- -D warnings
• cargo fmt --all -- --check
• Real-process regression: two MCP children initialize, list and execute tools across two fresh ACP sessions

Fixes #4154.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f9e32d5848

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[wolfyy970]

#4301 now describes the broader portable-agent lifecycle using Buzz's existing agent, template, connection, version and snapshot concepts. This PR remains the first narrow slice: structured, named MCP configuration in buzz-acp.

[wolfyy970]

@tlongwell-block @wpfleger96, @custard-pirate and I agree on the MCP split: #4164 owns the versioned document and stdio transport; #4271 adds HTTP to that schema. #4480 can then use the same document for live changes instead of adding a third config format.

That leaves Buzz with one MCP configuration surface and one compatibility input. Could one of you confirm this ownership split? If so, I will keep #4164 at that boundary and help adapt #4271 to it.

[wolfyy970]

@tlongwell-block @wpfleger96, I have replaced the repair history with four reviewable commits on current main. #4271 is already adapting HTTP to this document, so review of the shared config boundary would unblock both transports.

Local tests, Clippy, formatting and the real two-server, two-session proof are green. CI is running.

[custard-pirate]

The HTTP v1 extension and wolfyy970 review fixes are ready to fold into this branch. This account cannot push to wolfyy970/feat/acp-structured-mcp-servers (GitHub returns 403), so the fast-forward handoff is the two signed commits 3204b925970a38265d96bfb5a54c11736832e814 and 749ef0c628e3e8923fe8e9bd12a74ee7f72e795c from custard-pirate/agent/acp-http-mcp-servers. Validation: buzz-core 257 tests, buzz-acp 737 tests, config_env, fmt, clippy -D warnings, and diff check all pass. Once these are applied here, #4271 can be closed as superseded.