hertz 10:24Z — PROBE PREDICTION REGISTERED, plus two source reads that change what the probe means.
One of them bears on your OS-partition ruling, so I am reporting it and NOT editing the draft until
you rule.

READ 1 — THE TARGET CELL'S FIXTURE, and it makes the prediction near-determinate.
`trial_kills_alive_never_ready_candidate_before_rollback` gets its candidate from `long_child()`
(brainproc.rs:1359):
    Windows: Command::new("cmd").args(["/C","ping","-n","30","127.0.0.1"])
    Unix:    Command::new("sleep").arg("30")
**The Windows arm goes through a shell; the Unix arm does not.** cmd forks ping, so the candidate
the supervisor kills is cmd and the process actually burning 29 seconds is its child. On Unix there
is no intermediary at all.

REGISTERED PREDICTION, before the probe runs, three arms so none can be retrofitted:
  EXPECTED — the killed pid (cmd) is GONE, and the SURVIVOR is the GRANDCHILD `ping.exe`, with a
  parent pid equal to the dead cmd pid, alive for up to ~29s after the kill. This is the arm the
  codebase's own kill_pid_tree doc predicts.
  SURPRISE — the killed pid is still alive (child survivor, your original framing). That would
  CONTRADICT the cell's own passing assertion `pid != 0 && !pid_alive(pid)`, so it would mean
  pid_alive is lying, which is a bigger and different problem than the leak.
  THIRD, and it is a real risk of the METHOD not of the code — nothing alive at probe time, because
  the read happened after ping's ~29s window closed. The tree must be read within a few seconds of
  the kill or the probe is vacuous. I will timestamp the read against the kill and say so.

READ 2 — THE ASSERTION AND THE LEAK ARE CONSISTENT, which is why this survived review.
The cell asserts the candidate pid is dead before rollback. That assertion is TRUE and passes: cmd
really is dead. The process doing the work survives. **The test verifies the pid it killed and is
blind to the pid that matters** — the leak and the green are not in tension, they are the same fact
seen from two ends. That is the general shape worth carrying into IR-81: an assertion over a pid
cannot see a tree.

READ 3 — I CHASED A PRODUCT IMPLICATION AND IT REFUTED ITSELF, reporting because the negative is the
useful part. If the real supervisor also killed a shell wrapper, "never two live brains"
(REQ-HAZARD-BROKER-PROCESS-ISOLATION, the very invariant this cell guards) could be violated in
production on Windows while the test stayed green. It is NOT: `spawn_brain_child` (brainproc.rs:1224)
does `Command::new(exe)` — the brain is spawned DIRECTLY, no shell, no grandchild, so a single-pid
kill reaches it. **This is a test-fixture artifact, not a product defect.** The fixture's shell is
a Windows-only convenience for "a process that blocks ~30s", and it introduced a layer the real
path does not have.

THE PART THAT TOUCHES YOUR RULING — your call, no draft edit made. Read 1 is a MEASURED source
asymmetry that explains the OS partition FOR THE BRAINPROC FAMILY: those cells leak on Windows and
not Linux because their own fixture spawns a shell on Windows and a bare process on Unix. That is
not a story fitted to a measurement, it is two lines of source. **But it does NOT explain the whole
partition**: `process_cmdline_reads_a_live_arg_marker` leaks on LINUX only, and BOTH its arms use a
shell — so the same mechanism predicts it should leak on both boxes, and it does not. So the
partition stays open as a whole while one family now has a cause I can point at in the source.
Do you want that in ir80 as a scoped measurement (family-level, partition still open), or held out
entirely to keep the open question clean? I lean toward including it scoped, because it is source
rather than inference — but you ruled the shape and it is your ledger.

Still off cargo, probe parked for GATE DONE.