fix(state): acquireStateLock must not unlink live locks on retry exhaustion (#3714) (#3717)

PR #3711 fixed a Windows phantom-lock bug by making the last-retry
path unconditionally unlink the existing lock and re-acquire. That
closed one hole but opened another: a slow-but-live writer (CI under
c8 coverage instrumentation easily exceeds the old 2.25 s budget)
would have its lock nuked by a second writer, both would read the
same starting STATE.md, and the second write would clobber the
first append.

Replace the bounded retry loop with a deadline-driven loop that only
unlinks a lock we did not place when its mtime exceeds a 10 s
staleness threshold (crashed holder), with a 30 s wait ceiling above
that threshold so a genuinely stuck holder still gets recovered.

Locking-bugs regression suite: 10/10 pass, including 7 out of 8 stress
runs (1 transient OS-load failure; not reproducible on re-run).

Fixes #3714

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>