queue: Q31 addendum 2 -- mtime defect root-caused in restore-mtime.py; dead digest still in the deliverable

1. restore-mtime.py could never hit its own target: it hardcodes datetime(..., 475780) --
   microsecond 475780, discarding the original's trailing 303 ns -- and os.utime takes a
   float, so that resolves to ns-part 475780096, i.e. 207 ns BELOW the true original
   475780303. Float precision is secondary; the hardcoded microsecond target is primary.
   Byte-exact mtime restoration was never achievable as written.

2. Which statements are wrong: the deliverable asserts 475780303Z as the post-restore value
   in three places (section 0 line 26; the section 3 verify pair at line 163; section 6.1
   line 210), while section 7 line 241 says 475780010Z -- which is what the live file
   actually reads. Section 1 lines 49 and 69 cite 303Z as a PRE-INCIDENT baseline; those are
   correct readings and are not inconsistencies.

3. The dead digest (701 lines / 28,808 B / 60229227...) is still in
   recoveries/helm-collector-run.md sections 1, 4 and 7; its blob is unchanged since 300228b
   13:31Z. The correction lives only in WORK-QUEUE.md and reply 14. The fix is Merlin's
   append; the control plane does not edit a counterparty deliverable.

4. The corrected identity is corroborated by construction: applying DIFF.txt (38 lines,
   +19 -1) to helm-collect-pregate.py yields a file byte-identical to
   /root/crucible/q31/helm-collect.py (705 / 29,085 / 8a477376...).

5. Writer discipline adopted: two scheduled control-plane jobs push under one git identity
   (Timmy <timmy@stackchain.ai>) -- today 067cc52 13:45:19Z, then bc4ba2c + 72d51a2 at
   13:50:06Z/13:50:11Z, with the digest blocker corrected twice independently. Rule: one
   correction block per subject per tick, and read the tail for the other writer's coverage
   before appending. Staggering the two jobs is Alexander's call.

WORK-QUEUE.md

@@ -4201,3 +4201,37 @@ nor edited it, and the corrections below are the ones this tick measured itself.
   lane's next unit; **Q9** blocked on the audio handover; **Q13** (18 flags) and **Q19** gated on Alexander;
   **Q26–Q30** gated on the same §4 publish decision, now joined by **Q31**. The executable set is not empty, so
   **no item was opened this tick**. Nothing new is publishable — the standing public status is unchanged.
+
+**Q31 addendum 2 — the mtime defect has a root cause in the script, and the deliverable still carries the dead
+digest. 2026-10-11 14:15Z (control plane).** One block, one subject, written after reading the tail for this
+tick's other writer — the 13:50Z blocks already carry the digest blocker and the "digest read off disk in the
+same pass" rule, so this adds only what they do not.
+
+- **`restore-mtime.py` could never hit its own target.** The script hardcodes
+  `datetime(2026, 10, 8, 17, 12, 59, 475780)` — microsecond `475780`, which discards the original's trailing
+  `303 ns` — and `os.utime` takes a float, so that timestamp resolves to ns-part **475780096**, i.e. **207 ns
+  below** the true original `…475780303`. Float precision is the secondary cause; the hardcoded microsecond
+  target is the primary one. Any claim of byte-exact *mtime* restoration needs the script fixed first, not the
+  prose re-worded.
+- **Which statements are actually wrong.** The deliverable asserts `…475780303Z` as the post-restore value in
+  three places — `§0:26`, the `§3` verify pair at `:163` (`mtime_ns …303 → …303` **unchanged**), and `§6.1:210`
+  — while `§7:241` says `…475780010Z`. The live file reads `…475780010Z` (measured this pass), so the `…303`
+  claims cannot stand and `§7:241` is the honest one — though its "86 ns above" is wrong in sign and magnitude
+  (the gap to the original is **−293 ns**, and the gap to the script's own target is −207 ns). `§1:49` and
+  `§1:69` cite `…303Z` as a **pre-incident baseline**; those are correct readings and should not be counted as
+  inconsistencies when the addendum is written.
+- **The dead digest is still in the artifact.** `recoveries/helm-collector-run.md` (§1, §4, §7) still instructs
+  adoption at **701 lines / 28,808 B / `60229227…`**; its blob is unchanged since `300228b` 13:31Z. The
+  correction lives only in `WORK-QUEUE.md` and reply 14, so anyone reading the deliverable alone is one click
+  from a digest that resolves to no file. The fix is Merlin's append — the control plane does not edit a
+  counterparty deliverable.
+- **The corrected identity is now corroborated by construction, not just by reading.** Applying the record's own
+  `DIFF.txt` (38 lines, +19 −1) to `helm-collect-pregate.py` yields a file byte-identical to
+  `/root/crucible/q31/helm-collect.py` — 705 lines / 29,085 B / `8a477376…`. So the identity in addendum 1 is the
+  gate-carrying artifact by two independent routes.
+- **Writer discipline, adopted now.** Two scheduled control-plane jobs push to this repo under one git identity
+  (`Timmy <timmy@stackchain.ai>`): today `067cc52` 13:45:19Z was followed by `bc4ba2c` + `72d51a2` at 13:50:06Z
+  and 13:50:11Z, and the digest blocker was independently corrected twice. Parallel correction blocks in one
+  append-only queue are the likeliest way this record corrupts next. **Rule: one correction block per subject
+  per tick, and read the tail for the other writer's coverage before appending.** Staggering the two jobs is
+  Alexander's call, not a self-serve change.