A proxy that falls back to in-process serving keeps the project's writer lock for life #2277

What happened. After its daemon link dropped, a Claude Code session's proxy served in-process,
took writer.pid in fallback mode, and never let go. Every later daemon start for that repo failed
(daemon.log: "CodeGraph writer lock held by PID N (fallback mode) ... Failed to start server"), so
every other session on the repo ran read-only without auto-sync until that session ended. Observed
for hours on a live machine. (Possibly related to #2042, which addressed blocked fallbacks.)

Cause. proxy.ts (~395-406) switches to makeFallbackEngine, which takes the writer lock
(src/mcp/index.ts ~138), and nothing ever retries the daemon or releases the lock.

Suggested fix (what we did): the degraded proxy retries the daemon with backoff (5 s, capped at
5 min, env-tunable), stops the fallback engine first so the lock is released, and replays the client's
initialize to the fresh daemon; it never stops the engine mid-call.

Two related daemon findings, in case they are useful:

• The daemon/proxy compatibility check compares only the package version, so after a source rebuild at
  the same version a new client attaches to the OLD daemon (old code, the first launcher's environment),
  while tools/list comes from the new build. We stamp a build id (content hash of dist) plus an
  environment fingerprint into the hello.
• The liveness watchdog killed a healthy daemon exactly 60 s after "Listening", twice, during start-up
  catch-up (synchronous git ls-files, tree walk, SQLite on the main thread). We announce those phases
  to the watchdog and allow a bounded grace.

All found on Windows 11, Node 24, main at f416357 (2026-10-02), running as Claude Code's MCP server.
Each has a fix with a regression test in our fork (ijbranch/gllCodeGraph, private); the test and the
patch can be offered as a PR if wanted.