fix: the framework lock is a queue of owned tickets

[TheAmericanMaker]

Summary

Closes #355. Verified before changing: the issue's two claims are true of main by construction — withRemovalLock broke a stale .break with a bare rm (the same race #344 fixed one level up), and acquireLock broke any lock older than STALE_LOCK_MS with no way for a live holder to say it was still there. The new "live holder past staleMs keeps the lock" test cannot pass on the old design.

The redesign replaces the shared file with owned tickets (Lamport's bakery on a filesystem):

• Each waiter writes <lock>.t.<order>-<pid>-<token> beside the lock — its own file, written by it alone — after announcing <lock>.c.<token> at the doorway, so a waiter that took an earlier number cannot be overtaken before its ticket exists.
• The holder is the owner of the first ticket whose process is alive (process.kill(pid, 0)) and whose ticket was refreshed within staleMs. Every owner refreshes its ticket on an unref'd timer (staleMs / 4) while it waits and while it holds — a live holder is never broken by age.
• A dead owner's ticket is removed at once, a hung owner's after staleMs, a dead chooser's marker at once — each by its unique name via unlink, and brokeStale is recorded only by the caller whose unlink actually removed it (fs.promises.rm reports success to every concurrent caller, which is how the many-waiters test first reported eight breakers).
• Nothing shared is ever removed and re-created, so the class of race behind [self-audit D-H5] Status lock release removes whoever's lock is present, including a newer holder's #227 → acquireLock: two waiters breaking the same stale lock can both take it #342 → fix: every lock removal happens under a removal lock, so two stale breaks cannot both take the lock #344 → Stale-lock breaking is racy by construction and breaks live long holders #355 is gone rather than moved.
• A plain lockPath file from a pre-upgrade process is honoured while fresh and removed when stale, so an upgrade under a live older process does not let two writers in.
• acquireLock(lockPath, { timeoutMs, staleMs }); release() clears the heartbeat and unlinks the ticket. BREAK_LOCK_STALE_MS and the removal lock are gone. The four call sites (status, usage, library, broadside/state) are unchanged.

Test plan

• tests/state-store.test.mjs, rewritten lock section: a live holder older than staleMs is not broken (the waiter times out instead); a dead owner's ticket is removed at once and a hung one's after staleMs, with brokeStale recorded; release removes only the releaser's ticket ([self-audit D-H5] Status lock release removes whoever's lock is present, including a newer holder's #227 kept); eight waiters behind a dead ticket — one holder at a time, all served, exactly one breaker, nothing left behind; a dead chooser's marker is cleared and a live one blocks until withdrawn; a fresh legacy lock blocks and a stale one is removed. Run four times, stable.
• npm run build + npm test — 923 pass (the concurrent-publish, usage-append, and completion-commit tests exercise the lock through its callers).

🤖 Generated with Claude Code