fix(auth): stop deleting the winner's lock after a stale takeover (#2082)

Copilot review round 4 — four comments, all the same finding against the four
files carrying the claim, and it was more than a wording problem.

The comment said a holder whose lock was replaced is told. Checked against
proper-lockfile@4.1.2, that is false in the case that actually happens:

- `updateLock` compares mtime only on its refresh tick — `stale / 2`, so 5s
  here — while an ordinary mutation is a read, an scrypt derivation and an
  atomic write, comfortably under a second. The tick never runs, so nothing
  fires.
- `release` → `unlock` → `removeLock` is an unconditional `rmdir` with **no
  ownership check**. So the compromised holder goes on to delete the
  *winner's* lock on the way out, ending the winner's exclusion too: one
  compromised writer silently becomes two unprotected ones.

The second half is a correctness bug, not a documentation defect, and it is
fixable here even though the takeover race itself is not.

`withSecretFileLock` now records the lock directory's inode and birth time at
acquire and re-checks them before releasing. On a mismatch it **declines to
release** — leaving the new holder's lock alone costs nothing, ours is
already gone — and warns.

Inode and birth time rather than mtime, deliberately: both survive the
library's own `utimes` refresh, so a lock held past one tick is not accused of
being compromised, and both change on a delete-and-recreate, which is exactly
the event to detect. Where a filesystem reports neither, the two reads agree
and the check concludes "ours", degrading to the library's unaided behaviour
rather than to a false alarm. An unreadable baseline at acquire likewise
answers "ours" — with nothing to compare against, accusing a healthy lock
would be worse than releasing it.

Detection is therefore **best-effort**, and file-lock.ts, README.md,
specification/v2_servers_file.md and AGENTS.md now all say so rather than
promising the loser is told. AGENTS.md carries the negative instruction too,
since this is the second round spent on the same overclaim.

Tests: "does not delete the winner's lock after being taken over" replaces the
lock inside the body and asserts the replacement survives with the *same*
inode and birth time — it was left alone, not deleted and recreated. It waits
for nothing, being the fast case the library's tick misses. Verified by
mutation: forcing `stillOurs` to always answer true fails it. A second test
covers a release that fails while the lock genuinely *is* ours (a stray file
makes `rmdir` fail ENOTEMPTY), so the ownership check cannot swallow a real
release failure.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JTHVxSu8AUgHRLvo1ntZ8H
Signed-off-by: cliffhall <cliff@futurescale.com>

AGENTS.md

@@ -73,8 +73,13 @@ v2/main/
 │   │   │                               #     mutual exclusion #2082 settled on — proper-lockfile,
 │   │   │                               #     borrowed rather than hand-rolled. Read its header before
 │   │   │                               #     citing it: it makes two LIVE Inspectors exclusive, and
-│   │   │                               #     does NOT make stale takeover single-winner — it makes the
-│   │   │                               #     loser detectable (ECOMPROMISED), which is the honest claim.
+│   │   │                               #     does NOT make stale takeover single-winner. proper-lockfile
+│   │   │                               #     detects a takeover only on its 5s refresh tick, which an
+│   │   │                               #     ordinary sub-second mutation never reaches, and its release
+│   │   │                               #     is an unconditional rmdir — so withSecretFileLock does its
+│   │   │                               #     OWN ownership check (inode+birthtime) before releasing, to
+│   │   │                               #     avoid deleting the winner's lock. Detection is BEST-EFFORT;
+│   │   │                               #     do not write that a compromised holder is always told.
 │   │   │                               #     DEGRADES when no lock CAN be taken (read-only $HOME etc),
 │   │   │                               #     since this store exists for boxes missing the usual
 │   │   │                               #     mechanism; but THROWS on ELOCKED — a lock held by a live