fix(mcp): daemon stop closes pending sockets; a blocked fallback serves reads (#1963)

[danusha2345]

Fixes #1963. This implements the two changes @bompus proposed in the issue.

Problem

• Daemon.stop() can hang. 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 unregistered socket. The daemon keeps writer.pid while its socket is already unusable.
• The fallback refuses. When a live process holds the writer lock, makeFallbackEngine throws "writer lock held". The same happens on a daemon version mismatch, and when another session's fallback holds the lock, so one fallback locks every later session out of CodeGraph.

Fix

• Daemon tracks every accepted socket, destroys new connections that arrive while it is stopping, and destroys all tracked sockets before server.close(). A hello that resolves after stop began no longer creates a session.
• When a live daemon or another process holds the writer lock, the fallback returns new MCPEngine({ watch: false }). It serves reads from the WAL database, starts no watcher and claims no lock. The unreadable-lock and legacy-daemon refusals are unchanged.

Tests

mcp-daemon.test.ts:

• a daemon with a raw connection that never sends its hello exits on SIGTERM within 1.5 s;
• the two existing refusal tests (writer lock held, version mismatch) now expect a read-only codegraph_status answer, and still check that no writer.pid was claimed.

Full suite on this branch (Linux, Node 22, native kernel): all tests pass except the known extraction.test.ts pool-worker crash from #1779 (fixed by #1883), which is intermittent and also occurs on main; that file alone passes 655/655.

🤖 Generated with Claude Code

[bompus]

Thanks, go ahead with yours. I compared it with what our fork runs and the behavior matches: stop destroys pending sockets and drops connections that arrive mid-stop, and the fallback serves reads with no lock and no watcher, while the unreadable-lock and legacy-daemon refusals stay. I won't open a competing PR.

One optional extra: our fork writes a line to stderr when it falls back to read-only, e.g. [CodeGraph MCP] Serving reads in-process without auto-sync: <holder>. Otherwise a session that has quietly stopped syncing looks the same as a healthy one in the logs.

[danusha2345]

Thanks for checking it against your fork. Added the stderr line in 364d379: a read-only fallback now logs [CodeGraph MCP] Serving reads in-process without auto-sync: writer lock held by PID <n> (<mode> mode)., or live daemon PID <n> holds the project lock. when a daemon it cannot attach to holds the lock. Both fallback tests now assert the line.

[colbymchenry]

Thanks @danusha2345! Your commits here were carried into #2042 (authorship preserved), with a few follow-up changes from review, and that is now merged. Closing this one in favour of it. It will be in the next release.