fix: every lock removal happens under a removal lock, so two stale breaks cannot both take the lock

[TheAmericanMaker]

Summary

Closes #342. acquireLock broke a lock older than STALE_LOCK_MS with stat → rm. Two waiters that both saw the stale file both removed it; the second rm landed after the first waiter had re-created the file, so both held the lock. Every waiter polls on the same 125 ms cadence, so "two waiters see it stale in the same tick" is the normal case, not a corner.

Design (the issue's rename-then-rm idea does not close it — a rename takes whatever inode is at the path at that moment, a fresh lock included):

• All removals are serialized under a removal lock, <lock>.break (O_EXCL, held across one stat/read and one rm).
• Each removal re-verifies under it: a stale break re-stats the age; a release re-reads its token.
• A lock file can only be created while the path is free (wx), so nothing can be created between a remover's check and its rm, and only removal-lock holders remove: what was verified is what is removed. This also closes the narrower race where the original holder's late release and a stale break overlapped.
• A removal lock abandoned by a crashed process is cleared after BREAK_LOCK_STALE_MS (= LOCK_TIMEOUT_MS, 5 s; it is held for milliseconds). A release that cannot take the removal lock within LOCK_TIMEOUT_MS falls back to the token-checked removal alone — the guarantee before this change, never less.

acquireLock's API and the lock file format are unchanged; BREAK_LOCK_STALE_MS is exported beside the other constants.

Test plan

• tests/state-store.test.mjs, four new tests, all failing on main: a waiter that finds a stale lock being broken by someone else does not remove it (and does not remove the fresh lock that replaces it either); a release waits for a break in progress; an abandoned removal lock is cleared; eight waiters on one stale lock — exactly one breaks it, never two holders at once, no files left behind.
• Existing [self-audit D-H5] Status lock release removes whoever's lock is present, including a newer holder's #227 and acquireLock leaks the lock file handle when writeFile throws #131 lock tests unchanged and green.
• npm run build + npm test — 911 pass.

🤖 Generated with Claude Code