fix(acp): name the hung RPC method in request timeout errors

[bostonaholic]

Why

When an agent stalls on a non-prompt RPC, the harness surfaces only Request timeout — agent did not respond within 60s. The method name is dropped, so the desktop Activity panel and the harness log give the operator nothing to act on.

This bit hard in practice: an agent hung during session/new because its MCP extension startup was blocked on an unreachable package index. Five identical generic timeouts later, diagnosing required correlating the harness log, the agent's own logs, and network state by hand. An error naming session/new would have pointed straight at agent startup.

It is not a one-off. #3729 reports OpenCode-backed agents hanging on every model, and the entire log evidence available to the reporter is three identical copies of the generic message:

ERROR buzz_acp: agent initialize failed: Request timeout — agent did not respond within 60s agent=1
ERROR buzz_acp: agent initialize failed: Request timeout — agent did not respond within 60s agent=2

The actual stall was session/set_config_option rejecting a permission-mode value — a different call than the initialize the log implies. Pinning down which RPC hung took a hand-run ACP round-trip outside of Buzz.

Before / after

Every stall below produced a byte-identical message before this change:

Stall point	Before	After
Agent binary never came up	Request timeout — agent did not respond within 60s	Request timeout — agent did not respond to initialize within 60s
Stuck in startup / extension load	Request timeout — agent did not respond within 60s	Request timeout — agent did not respond to session/new within 60s
Auth handshake wedged	Request timeout — agent did not respond within 60s	Request timeout — agent did not respond to authenticate within 60s
Permission mode rejected or ignored (#3729)	Request timeout — agent did not respond within 60s	Request timeout — agent did not respond to session/set_config_option within 5s
Model switch wedged	Request timeout — agent did not respond within 5s	Request timeout — agent did not respond to set_model within 5s
Model switch via config option	Request timeout — agent did not respond within 5s	Request timeout — agent did not respond to configOption (configId=model) within 5s

The operator reads the failing subsystem straight off the line instead of inferring it from which log lines happen to sit nearby.

What

AcpError::Timeout now carries the RPC method:

#[error("Request timeout — agent did not respond to {method} within {timeout:?}")]
Timeout { method: String, timeout: std::time::Duration },

• send_request populates the method at both timeout sites (a send_request_with_timeout seam makes the path testable without a 60s wait)
• The model-switch and permission-mode timeouts in pool.rs report their operation the same way

Test plan

• New unit test: a silent agent times out on session/new and the error message names the method — confirmed failing before the fix (message had no method), passing after
• Full buzz-acp suite green
• cargo fmt --check, cargo clippy, and workspace cargo check clean

🤖 Generated with Claude Code