fix(agent_servers): serialize ACP session-creation per connection

[lukemarsden]

Summary

Adds a per-AcpConnection chain so concurrent new_session / load_session / resume_session calls dispatch their ACP RPCs sequentially rather than in parallel.

This is the next layer of the recurring "chrome MCP not working in spec tasks" bug (see helixml/helix#2352 for the corresponding sandbox-versions bump).

Why

Two concurrent calls to connection.new_session() cause claude-agent-acp to spawn two child claude SDK processes back-to-back. Each child runs npx <pkg>@latest in parallel for stdio MCP servers (chrome-devtools-mcp, server-github, etc). npm tarball extraction isn't safe under concurrent invocations on the same _npx cache directory: the loser silently fails to register its MCP child, leaving the active claude process without (e.g.) chrome-devtools-mcp.

Reproduced in two distinct spec-task containers:

• ubuntu-external-01kqvsbtsb4nc7pr14dy1zzfk9 — --resume <real> claude has no chrome-devtools-mcp, ghost --session-id <new> claude does
• ubuntu-external-01kpz66jwq1vk8ctzrj054byqq — same pattern (different IDs)

PR #46 deduped at the wrapper level (one claude-agent-acp per (project, agent_id)). PR #47 bumped context_server timeout to 180s. Both still in place. Neither catches the in-wrapper race.

What

• New session_creation_chain: Rc<RefCell<Option<Shared<Task<()>>>>> field on AcpConnection
• New acquire_session_creation_slot() helper returning (prev_chain, SessionCreationGuard)
• new_session and open_or_create_session (covers load_session and resume_session) take a slot at start, await prev, hold guard until response processed
• Drop guard ensures cancellation/error releases the slot — chain can't wedge
• Slot is acquired AFTER the pending_sessions dedup check, so same-id concurrent calls still share one task (existing behavior preserved)

Test

test_concurrent_session_creation_is_serialized:

• Two distinct-session-id load_session calls dispatched together
• First parks at fake-agent gate; second blocks on chain
• Asserts only 1 RPC reached the wire while first is parked
• After releasing gate, both complete; asserts 2 RPCs total

All 14 existing agent_servers tests still pass.

Caveat

This is a structural defence at the spawn point. The original trigger for two startup session/new calls in Zed (one for the saved thread, one for a "ghost" session whose cwd matches the workspace's first worktree path) is still unidentified — agent_panel.rs::load()'s draft branch is ruled out by saved KVP, and set_active→activate_draft is ruled out by base_view being sync-set before set_active fires. Likely candidates: MultiWorkspace's ActiveWorkspaceChanged flow, or zed.rs::ensure_agent_panel_for_workspace. Tracking as follow-up; this PR prevents the symptom regardless of source.

🤖 Generated with Claude Code