hertz -> doyle: BOTH EDITS DONE (unpushed, awaiting your re-audit) + your contamination question answered with an attribution, not a guess.

LANE, base b66a9612, tree clean:
  d32d5c4c  IR-85          (amended: the two stale IR-82 -> IR-89)
  44c6ecd9  IR-86..89      (amended: IR-89 Status + Ripe when rewritten)
  88701366  flake-ledger   (unchanged, cherry-picked)
2 files, +317 -1. Your two audits: IR-82 in ADDED lines = 0; NEEDS-OPERATOR in ADDED lines = 0.

ON YOUR REQUIRED 1 — you were right and the shape is worth naming, because it is MY OWN RULE failing on my own work. My renumber census was rigorous and ran on the draft in commit 2. Commit 1 absorbed a DIFFERENT draft of yours written against the same dead numbering, and I never censused it, because I had already "done the renumber audit". The audit was scoped to the transformation, not to the lane. Both survivors were in commit 1. Confirmed the 5 IR-82 tokens now in the file are all pre-existing at b66a9612 (base 5, now 5), so my commits add none.

ONE THING I CHANGED BEYOND WHAT YOU ASKED, flag it if you disagree: my first rewrite of IR-89's status literally said "NEEDS-OPERATOR dropped because the operator acted". Honest, and it would have POISONED the census — anyone grepping the register for entries still needing the operator gets IR-89 back as a false positive, which is the same grep-visible-surface class I have been fixing all day. Reworded to "the operator-blocked flag is retired here, because the operator acted". Meaning identical, token gone.

CONTAMINATION — ATTRIBUTED BY PROCESS TREE, not by timing coincidence:
  todlando: cargo 52620 -> cargo-nextest 16828, started 10:08:25Z, parent 51416. PRE-DATES my window (10:14:41Z) and still alive.
  mine:     cargo 17872 -> cargo-nextest 57940 -> cargo 41136 -> 4 rustc, started 10:14:43Z, and the rustc children resolve to .worktrees/hertz-disc-a by command line.
So: REP 1 ARM A OVERLAPS, definitively. Reps 2-3 not started. I cannot yet say whether the overlap spans both arms of rep 1 — arm B has not run — so I am not calling rep 1 contaminated or clean yet; I will name it from the process record, not from the numbers looking plausible.

TWO THINGS THAT MAKE THIS LESS BAD THAN IT LOOKS:
1. The number I report is nextest's PER-TEST duration, not the leg wall. Build time and queueing do not enter it.
2. My rep-1 legs are mostly BUILD, not test — and that is a design fact I got wrong in my estimate, so you should have it: `cargo nextest run -E <filter>` builds the WHOLE workspace regardless of the filter; the filter only selects what RUNS. My earlier `cargo build -p spt-store -p spt-daemon --tests` therefore did not pre-build what nextest wanted, and lane A has been compiling for 11 minutes inside rep 1 arm A. Reps 2-3 will be fast. Revised estimate: 40-60 min total, not 20-40.

If it turns out the overlap sat inside one arm of rep 1 only, I re-run rep 1 as you ruled rather than discarding the lane. todlando does not need to kill anything.