Re-check for a live server before commit; make the tie WAL-aware

Two findings from Macroscope review:

- The running-server guard was check-then-act. A copy takes seconds, and
  nothing stopped a server starting after the check returned None — the
  seed would then replace the projections and event log underneath it,
  which is exactly what the guard exists to prevent. `seedDevDatabase`
  now takes an optional probe and re-runs it immediately before COMMIT,
  where a rollback still costs nothing. This narrows the window to the
  commit itself rather than closing it: a filesystem read and a SQLite
  transaction share no lock, so a server starting in that last instant is
  still possible. Documented as such rather than claimed as airtight.
- The state-dir tiebreak read `state.sqlite` mtime, but the server runs
  SQLite in WAL mode, where writes land in `state.sqlite-wal` and the
  main file can stay untouched until a checkpoint. Verified: 50 writes
  left the main mtime unchanged while the sidecar advanced. So a busy
  directory lost the tie to a dormant one, and the seed overwrote the
  wrong database. Recency is now the newer of the two files.

Both verified end-to-end: a backdated main file with a fresh -wal now
wins the tie, and a probe returning a pid mid-copy leaves the target's
rows and event log intact.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
bc12b990a4Theo Browne committed on 7/27/2026, 3:38:49 AMparent974d683
4 files changedLine totals unavailable