[valthon]

Summary

withFileLock left proper-lockfile's default onCompromised in place, and that default re-throws from the library's own unref'd mtime-refresh timer. When a held lock's directory disappears under a live holder, the refresh's stat fails with ENOENT, proper-lockfile rewrites the error in place to ECOMPROMISED (keeping the ENOENT … wire-cluster-ports.lock.lock text), and the throw lands as an uncaught exception with no relationship to the caller that owns the lock. Under jest that fails whichever test happens to be running, which is why the bind-registry signature kept surfacing in a different suite each time (ClusterBuildDefaultsEpochBootstrap, NodeConfig, OperatorFunding, ClusterConfigProvider) and passed on retry.

The fix is the handler and nothing else:

• withFileLock owns onCompromised: the in-flight critical section rejects with a NestedError carrying proper-lockfile's error as the cause, so the call that lost exclusivity is the call that fails. The section itself is not cancelled and its side effects are not undone; the public JSDoc says so.
• A section that fails after the compromise already decided the outcome is logged at warn instead of vanishing. An ordinary section failure is not logged, since the caller receives it.
• proper-lockfile's options (stale, update, retries) are unchanged from master. Every observed compromise on this host was the lock directory being deleted under a live holder (a test aborted at its 120 s budget while its fixture cleanup removed the sandboxed registry dir); the stale-steal signature appeared zero times, so no threshold tuning is warranted here.
• The stale root jest.config.ts comment that still described the timer throw is updated.

Diff: 3 files, +161/−8. Mechanism verified against proper-lockfile 4.1.2 source and reproduced with a standalone probe before the fix.

Verification

Check	Result
pnpm build, pnpm run lint	clean
pnpm test (full, idle host, on master 2d703304)	229 suites, 2080 tests, all passing; zero lock.lock signatures in the run
tests/utils/fsUtils.test.ts	11 passing, including a deterministic compromise reproduction (lock dir removed under a held lock) that fails with the exact uncaught timer throw when the handler is removed

🤖 Generated with Claude Code

https://claude.ai/code/session_01CNDguHHWTwn1UBejDiTAGa

[valthon]

CI note: the Build and test failure here is master's, not this PR's. The job installs the published @wireio/sdk-core (1.0.89 in the log), which predates the setscorecfg / rank_score types #94 introduced, so packages/cluster-tool prepare fails in SystemContractSteps.ts and producerRankUtils.ts before any test runs. master's own last run on 2d703304 (this PR's base) fails with the identical TS2724 / TS2339 set; this PR touches only fsUtils.ts, its test and jest.config.ts. It clears once wire-libraries-ts publishes the sdk-core release carrying those types. Local gate on the same base, against the sibling-linked sources: 229 suites, 2080 tests, all passing.