Shared-daemon sessions lose CodeGraph with "writer lock held": stop() waits on an unregistered connection, and a blocked fallback refuses instead of reading (1.6.0) #1963

Version: 1.6.0 on Linux (WSL2), several concurrent MCP sessions on one checkout.

Sessions intermittently get only CodeGraph writer lock held by PID <n> (daemon mode) back from every tool call and never recover. Two things combine:

1. Daemon.stop() can hang on a connection it accepted but never registered (src/mcp/daemon.ts:345, :381). A launcher that connects just as the daemon starts stopping is accepted, but it only joins clients after its client-hello. stop() closes the sessions in clients, then awaits server.close(), which waits on that socket. Meanwhile the daemon keeps writer.pid, and its socket is already unusable. Each new launcher fails its connect, its replacement daemon exits because the lock is taken, and after ~6 s (DAEMON_CONNECT_MAX_RETRIES × 25 ms) it falls back.

2. That fallback refuses whenever a live process holds the writer lock (makeFallbackEngine, src/mcp/index.ts:96). The session gets the error on every call. The same refusal also fires when the daemon runs a different version, and when another session's fallback already holds the lock. In that last case one fallback locks out every later session on the project for its whole lifetime.

Reproduction:

1. Client A attaches, and the daemon starts.
2. Open a raw connection to the daemon socket and send nothing, then kill -TERM the daemon. It stays alive, writer.pid stays, the socket is gone.
3. Client B's first tool call fails after 6.07 s with "writer lock held (daemon mode)".
4. Close the raw connection. The daemon exits, and B's next call succeeds in-process, with B now holding the lock in fallback mode.
5. Client C fails the same way, with "held by PID (fallback mode)".