#3470 Run index repair-by-stat misses an in-place, same-size record rewrite that restores mtime within the same second as its entry: ctime is reported in whole seconds

Summary

Found while fixing swamp-club#3467. Deno 2.9.7 on Linux reports a file's ctime truncated to whole seconds (kernel …:32.802, Deno …332000). RecordFingerprint (src/infrastructure/persistence/workflow_run_index.ts) relies on ctime and inode to tell a record rewritten in place apart from the version its index entry was built from, because utime can set the mtime back but not the ctime.

With second-resolution ctime, a record rewritten in place with the same size and its mtime restored (cp -p, rsync --inplace -t style), in the same wall-clock second as the save that wrote its index entry's fingerprint, keeps an identical fingerprint. findSuspectRecords (index repair) and verifyIndexes (swamp run doctor) then treat it as unchanged and keep the stale entry until that run is read directly.

This predates #3105; it has been so since repair-by-stat landed in #2859 (swamp-club#3051). swamp-club#3467 fixed only the run index snapshot cache, by counting a recent index ctime as racy, and left record fingerprints alone.

Fix ideas

• Treat an entry fingerprint as racily clean when the record's mtime or ctime is within about a second of when the index entry was written (git's racy-clean handling), and read such records during repair and verify.
• Or store the time the entry was written, and distrust any fingerprint whose ctime is not strictly before it.

Environment

Linux x86_64, Deno 2.9.7.