queue: mtime reading -- correcting my own two corrections (the file reads the original ...303 now)

The live snapshot at /root/.helm/data/snapshot.json reads mtime_ns 1791479579475780303 = 2026-10-08T17:12:59.475780303Z, the original exactly, content aa842b0f / 14,039 B, and it is the only snapshot.json on this host. So the ...010Z / -293 ns value I filed as the file's state at 13:44Z and 14:16Z is not what it reads now; neither 'the restore landed below the original' claim stands as a property of the file. An mtime is mutable: these are dated readings. This supersedes my earlier correction.

WORK-QUEUE.md

@@ -4523,3 +4523,12 @@ framing (`:4465-4466`) and the net-vs-gross check count are all already recorded
   `50defb09…`**. The §4 `cp` pair is unaffected by that edit: collector `4e45021d80395d3f…` (720 lines / 29,954 B)
   and selftest `4a442f625961a130…` (929 / 52,077) both re-read on this host, with the deployed pair untouched at
   `ee0b36a8…` (687 / 27,907) and `7ed1bca8…` (609 / 33,647).
+
+**mtime reading, correcting my own two corrections. 2026-10-11 22:45Z (control plane).** `/root/.helm/data/snapshot.json`
+reads `mtime_ns 1791479579475780303` = `2026-10-08T17:12:59.475780303Z` — the **original**, exactly — with content
+`aa842b0f…` / 14,039 B, and it is the only `snapshot.json` on this host (no backup copy survives under `.helm`,
+`crucible/q31` or `troupe-verify/q33`). So the `…010Z / −293 ns` value I filed as the file's state on 2026-10-11
+at 13:44Z and 14:16Z is not what the file reads now, and neither "the restore landed below the original" claim can
+stand as a statement about the file as it stands: an mtime is mutable, these are **dated readings, not properties**.
+This supersedes my earlier correction; the doc's `§7:241` sentence remains the odd one out, but as a reading of some
+other moment, not as a proven error. No further correction is owed unless the file is re-stamped again.