feat(acp): support remote HTTP MCP servers

[custard-pirate]

Summary

• add typed ACP Streamable HTTP MCP server support alongside the existing stdio server
• load remote URLs and headers from literal values, protected value files, or named entries in protected environment files
• fail before session/new when the selected runtime does not advertise agentCapabilities.mcpCapabilities.http
• redact stdio environment values and HTTP header values from ACP wire logs and observer events, and zeroize serialized credential-bearing buffers after writes

Why

buzz-acp currently exposes only one local stdio MCP command. That makes authenticated remote MCP services require either a transport bridge or a downstream ACP patch. Supporting the ACP HTTP server variant lets operators attach role-scoped remote tools without replacing the built-in stdio tool surface.

This is a generic, headless subset of the transport and security work explored in #3286. It deliberately omits the Patina-specific connection lifecycle, prompt guidance, and Desktop UI. It is complementary to #2900, which adds multiple stdio commands rather than the ACP HTTP transport.

Security and behavior

• public endpoints require HTTPS; plain HTTP is accepted only for literal private IPv4 or unique-local IPv6 addresses
• each URL and header must resolve from exactly one configured source
• credential-bearing header values can remain in protected files rather than process arguments or ordinary environment values
• header values use redacted Debug implementations and are removed from wire logging and observer frames
• runtimes without advertised HTTP MCP support fail closed before receiving server credentials
• existing configurations with no HTTP servers are unchanged

Validation

• cargo test -p buzz-acp --lib — 666 passed
• cargo clippy -p buzz-acp --all-targets -- -D warnings
• cargo fmt -p buzz-acp -- --check
• git diff --check

The published patch was also checked for deployment-specific domains, addresses, identities, and credential material; it contains only generic examples under example.test.

[wolfyy970]

@custard-pirate, I had already built #4164 before I came across this PR. It covers named stdio MCP servers, isolated per-server environments, compatibility with the existing command setting and secret-safe launch configuration. This PR covers remote HTTP transport, so the work is complementary, but both currently define the configuration shape that reaches ACP.

The practical win is one reviewable configuration for both local and hosted tools, with credentials scoped to the individual server. I think the clean merge is a single versioned typed document with stdio and http transports, while BUZZ_ACP_MCP_COMMAND remains a compatibility input rather than a second permanent schema. Projects should own concrete endpoints and credentials; portable agent templates should declare logical tool requirements.

I opened #4301 with the broader product shape and proposed PR split. I would like to align these schemas rather than leave Buzz with two permanent configuration surfaces.

[custard-pirate]

Thanks — agreed. A single versioned, typed MCP configuration with stdio and http transports is a cleaner long-term shape than introducing parallel configuration surfaces. Keeping BUZZ_ACP_MCP_COMMAND as a compatibility input also makes sense.

I’m happy to align #4271 with #4164. I’ll review its configuration model and #4301 in more detail, then we can coordinate the shared types and PR boundary so the two changes remain complementary. In particular, I’d like to preserve per-server credential isolation for HTTP servers without putting concrete endpoints or secrets into portable agent templates.