fix(cli): allow Windows project-lock preparation to complete

[swqsldz]

What does this PR do?

Fixes #2656.

A CLI mutation can repeatedly time out before it finishes Windows native lock preparation: the old 100 ms attempt expires while ownership/path/ACL checks are still progressing, so the outer retry discards partial work and starts over.

Use a 5000 ms Windows-only per-attempt budget. Other platforms retain 100 ms. Saturating deadline arithmetic, nonblocking calls, the native security checks, lock ordering, and cleanup semantics are preserved.

Change and regression coverage

• Share the attempt-deadline calculation between the real CLI call site and its regression through a small inline helper.
• Forward the existing idle-only lock-registry stage hook through an internal test accessor; no new environment-controlled seam is added.
• Add a Windows regression which delays native preparation by 150 ms after a turn lock is held. It checks that the previous 100 ms budget rolls back, the CLI budget acquires, another manager remains excluded, and acquisition succeeds again after release.

This changes five C/header files. It changes no MCP arguments, configuration defaults, dependencies, or build rules.

The large-database watch-registration issue #2655 is separate and is already addressed by the predicate replacement in #2639; that fix is intentionally absent from this branch.

Verification

• Changed files: clang-format 20.1.8 dry-run and staged whitespace checks passed.
• DCO: the human account owner explicitly authorized the sign-off; the commit has a matching author and Signed-off-by trailer. The upstream DCO check passed.
• Upstream production-build and smoke checks passed on Windows, Ubuntu and macOS. Upstream whole-tree lint and subsequent test lanes are still pending.
• The canonical Windows focused run has not completed; no passing project-lock regression result is claimed yet:
  scripts/test.sh --suites project_lock BUILD_DIR=build/upstream-lock-tests
  using an isolated Clang/MinGW UCRT 22.1.8 toolchain with ASan/UBSan and locally built zlib.
• Two earlier local build attempts failed in the validation command: first the zlib include directory was missing; then overriding LDFLAGS_TEST accidentally omitted the upstream mimalloc --wrap options (__real_free / __real__msize were unresolved). These are not regression results. The corrected run supplies zlib through CPATH / LIBRARY_PATH and retains all upstream link flags. The isolated zlib/sanitizer compile-and-run probe passed.
• The local canonical whole-tree lint run is also unfinished. It has reported a signed-long/INT_MAX range diagnostic at unchanged src/foundation/limits.c:39; no whole-tree lint pass is claimed.
• Before this upstream submission, a local v0.12.0 build containing the larger lock budget and the separate Windows: graph DBs larger than 2 GiB silently fail daemon watch registration #2655 predicate fix completed the affected full rebuild and automatic add/delete checks. That combined end-to-end result is supporting runtime evidence, not an isolated regression result for this branch.

This remains a Draft while the focused regression and complete CI are pending. Fresh-cache CLI follow-up fixtures were rejected before indexing by saved-runtime-settings initialization; those failed fixture attempts are not counted as lock reproductions.

Checklist

• Every commit is signed off.
• Canonical focused tests pass locally — running.
• Full test suite passes — not yet established.
• Whole-tree CI lint passes — pending.
• Regression added for slow native preparation, mutual exclusion, and cleanup — execution pending.

Written with Codex assistance on behalf of the account owner.

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.