fix(acp): advertise protocol version 1 until v2 is fully implemented

[santhiprakash]

Summary

buzz-acp was sending protocolVersion: 2 in the initialize request while still using the v1-shaped clientInfo/clientCapabilities body and consuming v1 response fields (e.g. stopReason in session/prompt and agentInfo/serverInfo in the initialize result). V2-capable adapters such as agy-acp therefore negotiated v2, validated the request against the v2 schema, and rejected the handshake with -32602 because the required info field was missing.

This change reverts the advertised version to 1 and updates the inline comment and the unit test to match. Sending a v1 request lets v2-capable adapters downgrade to v1, which buzz-acp already implements end-to-end.

Related issue

Fixes #4728.

Testing

• cargo test -p buzz-acp — all 668 tests pass.
• just fmt-check passes.
• cargo clippy -p buzz-acp --all-targets --all-features -- -D warnings passes.

The full workspace just clippy/just ci could not be completed locally because the environment disk was exhausted while compiling the broader workspace after the buzz-acp verification. CI will run the remaining gates.

[santhiprakash]

Closing this. On a fresh re-read of the current code, build_initialize_params() keeps protocolVersion: 2 with an explicit code comment (crates/buzz-acp/src/acp.rs:599-600):

// Requesting version 2 is an intentional temporary pin — we are squatting
// on ACP v2 ahead of the upstream ACP RFD. Revisit when that RFD merges.

That's a deliberate, documented maintainer decision to advertise v2 early, not an oversight — so this PR is re-litigating a settled stance rather than fixing a drift. The recent #5195 (ACP v2 messageId handling in buzz-agent) also shows v2 work is actively landing, which reinforces keeping the v2 advertisement.

Thanks for the consideration; happy to reopen if the RFD outcome or adapter-interop evidence makes v1 the right call.