MCP: the auto-connected companion falls back to legacy when a workspace server connected first

[justrach]

Found while validating the 2026-07-28 support on release/v0.0.225 against codedb-pro 0.2.16 (which speaks the new spec).

Repro, with a modern stdio server on PATH:

1. Workspace with a .mcp.json naming the same binary explicitly:
   {"mcpServers":{"cdbpro":{"command":"/Users/you/bin/codedb-pro","args":["--mcp"]}}}
2. graff --yolo -p "say OK" prints, every run:

[mcp:cdbpro]    connected (mcp 2026-07-28) — 12 tool(s)
[mcp:codedbpro] connected (mcp 2025-11-25) — 12 tool(s)

Same binary, same --mcp, two different negotiated revisions. cdbpro comes from Registry.init; codedbpro is the auto-activated companion added later via session_start.connectCompanion -> Registry.addServer.

3. Remove the .mcp.json and the companion alone negotiates correctly:

[mcp:codedbpro] connected (mcp 2026-07-28) — 12 tool(s)

So the companion path probes fine in isolation and only degrades when a workspace server connected first. Both paths reach Registry.startServer, which gates on the same reg.stdio_probe field, so the flag itself is not the difference; something about the second spawn in the same registry is.

Why it matters: the companion is the MCP server most graff users actually have connected, so this is the common case silently getting the legacy protocol while a hand-written .mcp.json entry gets the modern one.

Not a correctness bug (legacy is a valid, working negotiation and every tool call succeeds), which is why it is filed rather than held for the release. Worth a look at addServer -> startServer ordering and at anything the first server leaves behind on the registry.

[justrach]

Still reproduces on main @ cb02e90 (runtime-verified with this issue's exact repro: workspace stdio server first → companion lands on mcp 2025-11-25; alone → 2026-07-28). Investigation pointer for the fix: since codedb-pro provably answers the revision probe fast in isolation, the deterministic every-run fallback smells like one of the two silent legacy-degrade arms in src/mcp_rpc.zig — select.concurrent(.replied, …) catch return .legacy (:295) or select.await() catch return .legacy (:302), i.e. a concurrent-task/Io resource held by the already-connected first server — not the 600ms timeout arm (:308-311). Reached from the stdio branch of startServer at src/mcp.zig:413-431.