hertz 10:20Z — all three rulings applied. Draft edits done (no cargo touched, still off both boxes).

(1) OS PARTITION is now an OPEN question in ir80 with my "I do not have that explanation yet" kept
verbatim, plus one line saying why it is recorded WITHOUT a candidate cause: the partition is a
measurement, and pairing a striking measurement with a plausible story is exactly how "8 -> 5 is
favourable" got into the record. Whoever takes it should reach a cause by reading, not inherit one
from me.
(2) Calibration tiers left exactly as written — VERIFIED (two Linux cells), CONSISTENT-but-unproven
(the Windows kill family), UNVERIFIED (brainproc / broker / spt-live).
(3) RIDER 4 written, the test-side fix, mine, rides the IR-37 thin PR.

AND THE MECHANISM IS NOW CORROBORATED BY THE CODEBASE ITSELF, which I did not expect. `kill_pid_tree`
lives at crates/spt-store/src/proc.rs:430 and carries this doc comment:

    a single-pid `kill_pid` leaves the wrapper's harness children orphaned + running

That is the grandchild mechanism verbatim. **I derived it from the LEAK verdicts BEFORE reading that
line** — so the codebase's own documentation independently states the thing I inferred from the
symptom, at the helper that fixes it.

THE SHARPEST FACT, and it is a good one: the leaking cell and the helper it should call are in the
SAME FILE. proc.rs holds kill_pid_tree (line 430), a dedicated test proving it works
(kill_pid_tree_kills_the_whole_subtree, line 929, spawns a two-level tree, and it is absent from the
12-cell union at EVERY sha on BOTH boxes), and process_cmdline_reads_a_live_arg_marker, which builds
the same two-level shape and tears it down with child.kill(). One module, the right tool, the wrong
call, and a sibling cell already demonstrating the difference by not leaking.

THE CHANGE (both one-liners, no new dependency — spt_store::proc:: is already reached from
spt-daemon at broker.rs:465-470):
  proc.rs      kill_pid_tree(pid); then keep child.wait()   [pid already bound for the probe]
  livehost.rs  kill_pid_tree on BOTH psyche and sibling — that cell spawns TWO shells, so it
               orphans TWO sleepers, which is why it is the 2-leaky box's second member
DO NOT let a reviewer "simplify" the shell out of the fixture: the trailing `; :` is load-bearing,
it stops the shell being tail-exec-replaced by sleep so /proc/<pid>/cmdline still carries the marker
the test asserts on. The grandchild is intrinsic to the fixture; only the teardown was wrong.

ONE CAVEAT I PUT IN THE RIDER RATHER THAN HIDING: in proc.rs the teardown would call the function
the module tests, so a kill_pid_tree regression would show as a RETURNING LEAK instead of a failing
assert — a weaker signal. I judge it acceptable because kill_pid_tree_kills_the_whole_subtree
asserts the helper directly and goes red first, so the circularity is covered by a dedicated cell.
Flagging it so a reviewer gets to disagree rather than discover it.

Probe still parked for GATE DONE — on this box, pool claimed from my own tree, reading the TREE not
the count: after the kill, child or grandchild.