fix(mcp): keep ADR reads nonblocking during reindex

[SS-42]

Summary

• keep manage_adr(get|sections) on query-only store access while a same-project reindex holds the mutation lease
• preserve serialized manage_adr(update|store) writes through the existing native project-lock manager
• return legacy-file ADR content immediately; migration retries only after a nonblocking lease and rechecks the current SQLite generation before writing

Environment observed

• macOS arm64
• multiple independent MCP/CLI processes sharing one CBM_CACHE_DIR

Regression coverage

• stored ADR get and sections bypass a busy blocking mutation guard
• update remains serialized through the primary mutation guard
• a busy legacy migration returns readable content without blocking; a later successful try-acquire persists it
• corrupt-store recovery uses the nonblocking path for ADR reads

Verification

• git diff --check
• bash scripts/lint.sh --ci
• bash scripts/test.sh (6788 passed, 0 failed, 4 skipped across 121 suites)

[DeusData]

Thanks for the process-serialization work. Triage: high-priority stability bug.

Review will focus on lock scope and failure behavior: same-project serialization without blocking unrelated projects, no watcher/self-lock deadlocks, safe stale-store reopen behavior, and ADR migration/write ordering across independent MCP/CLI processes.

[DeusData]

Thanks — this addresses a real gap (independent MCP/CLI processes sharing one CBM_CACHE_DIR had no cross-process serialization), and the lock hygiene is right: 0600 lock files under the cache dir, FD_CLOEXEC, unlock-before-close, per-project scoping so unrelated indexes don't serialize, and project names are sanitized upstream so the lock filename is traversal-safe. The fork-based cross-process tests are a nice touch. Two changes requested before merge:

1. Vacuous pass in test setup (tests/test_mcp.c, the new lock tests): if (!cbm_mkdtemp(cache)) { PASS(); } turns a setup failure into a green test. Our suite treats that as a broken guard — a test that cannot establish its preconditions has FAILED, not passed (see the FAIL() macro doc in test_framework.h). Please use FAIL("mkdtemp failed") there (and in any sibling occurrences in the new tests).

2. Windows is a silent no-op — cbm_pipeline_try_lock_project returns true unconditionally under _WIN32, so Windows keeps today's cross-process races. That's a fine incremental scope (no regression), but please make it explicit: a comment at the #ifdef stating the limitation (+ ideally a one-line debug log), so the next Windows-locking pass knows this is intentionally unimplemented rather than accidentally missing. If you're up for it, LockFileEx on the same lock-file path is the natural follow-up — separate PR is fine.

Everything else looks merge-ready: 19/19 checks green, clean mergeable state against current main (impressive, given how much mcp.c/pipeline.c moved this week), scope matches the description exactly, no stray files.

[SS-42]

Addressed both requested changes in 0a8b63e: test setup now fails on mkdtemp errors, and the Windows lock limitation is explicit with a debug log. Also tightened cancellation and test cleanup.

[DeusData]

Thanks @SS-42 — reviewed in depth and the mechanism is sound: POSIX fcntl advisory locks are the right choice (they auto-release on process death, so there are no stale lock files to garbage-collect), the lock filename is path-traversal-safe, and there's no ABBA/self-deadlock. We'd like to take this, with two changes before merge:

1. Don't let ADR reads block behind a reindex. Right now manage_adr takes the blocking pipeline lock for all modes, so a get/sections read can hang for minutes behind a same-project full reindex in another process. Please give the read paths a non-blocking/try-lock-with-timeout path (serialize writes, but let reads proceed or fail fast rather than hang).
2. Rebase onto current main. The base has diverged a lot (the cbm_pipeline_lock() sites and handle_manage_adr have moved), so this needs a rebase + a green re-run before we can merge.

The Windows no-op is fine as documented (it's not a regression — there was no cross-process lock there before). Really appreciate this.

[SS-42]

Rebased onto current main. get and sections now use read-only access without waiting for a project mutation; legacy migration is nonblocking, while updates remain serialized. Added regression coverage and reran the full suite.