Make the file-lock timing check deterministic

[rotwurstesser]

Summary

• record the timing start before launching the child release process
• preserve the strict waited > staleMs assertion
• remove child startup time from the test margin

Verification

• corrected assertion: 20/20 isolated repetitions passed
• npm run kern:compile
• npm run typecheck
• npm run build
• npm run test: 306 files passed, 4,612 tests passed, 6 skipped

Closes #284

[rotwurstesser]

Reviewer note:

The original test started the timer after the child process launch. Child startup time then consumed part of the 50 ms assertion margin.

This change starts the timer before the launch. It does not change the lock implementation or weaken the strict waited > staleMs assertion.

Evidence:

• The corrected test passed 20 consecutive isolated runs.
• The full local suite passed.
• GitHub CI passed.

[rotwurstesser]

Merge order:

Merge this pull request before #287 and #282.

#287 needs this test correction before its isolated branch is fully reliable. #282 needs this correction before its CI rerun.

#283 is independent.

[cukas]

Verified independently: ran the file-lock suite at this ref in a clean worktree — 14 passed / 1 skipped. Starting the clock before the child launch can only widen waited, so the strict > staleMs assertion only gets safer, and the lock implementation is untouched. Approving first per your merge order — the CI red on #281/#282 traces back to this flake.

[rotwurstesser]

LGTM.

The current head is green and has formal maintainer approval. The change removes child startup time from the assertion margin without changing the lock implementation or weakening the strict timing assertion.