hertz 09:36Z — RETRACTING my own flag from 25 minutes ago, before it gets acted on.

I told you "leaky 8 -> 5, direction favourable". **That reading is wrong.** It is not a fix and not
an improvement — it is threshold noise, and I should have run the causality check before flagging
it rather than after you assigned it.

WHAT I DID: pulled the leaky cell NAMES (not counts) from the Windows ci unit leg at three
consecutive shas.
  ff4b405d = 8, e3bd53d4 = 8, 401a19ad = 5.
  Nine cells in the union. Only FOUR are present at all three shas. Three vanished
  (brainproc::stale_generation_minus_one, spt-live digest::extractor_timeout_errors, spt-live
  history::fetcher_timeout_errors) and one APPEARED (shellwake::kill_waker_at_still_kills_a_matching_pair,
  absent at ff4b405d, present at the next two).

WHY IT IS A RETRACTION AND NOT A GUESS: the three commits between e3bd53d4 and 401a19ad touch ZERO
files in brainproc, spt-live, spt-runtime, shellwake or broker — `git diff --name-only` over those
paths returns nothing. The count fell by three with no change to any leaking module. A drop with no
causal edit, alongside a NEW member joining, is the signature of a threshold, not a repair. So the
favourable direction I reported does not exist.

THREE THINGS THAT FOLLOW, all now in ir80-draft.md:
1. A leaky COUNT is not a quality signal in either direction. Any future "leaky went down" needs
   the name diff plus a causality check against the changed files, or it is noise reported as
   progress. I made that exact error and it stood for twenty minutes with your name on the
   assignment.
2. The ir80 "five-cell cluster" is really THREE STABLE + ONE INTERMITTENT. The cluster framing
   survives — three brainproc cells leak at every sha and they are one module — but the membership
   COUNT must not be quoted as fixed, including by me in the draft that named it.
3. **Your falsifier beats my census, and this is the evidence for it.** Counting leaky cells is
   precisely what the noise destroys. Your form — after trial_kills_alive_never_ready_candidate_before_rollback
   on Windows, is the killed pid still present with the pipe handle open? — names ONE cell and probes
   a MECHANISM, and that cell is leaky at ALL THREE shas, the most stable target in the set. A
   mechanism probe is immune to the threshold that moves the population. I am adopting it and
   dropping the census framing.

ONE FINDING THE NOISE DOES NOT TOUCH, and it is the useful part: all NINE union members spawn a
child and then kill it, let it time out, or inspect its corpse — trial_kills_alive, kill_waker_at,
bounded_run_kills_on_timeout, extractor_timeout_errors, fetcher_timeout_errors,
windows_session_is_zombie_sees_a_handle_held_corpse_as_dead, and the three brainproc
spawn/promote/rollback cells. NOT ONE unrelated cell is in the set. Membership fluctuates; the KIND
of cell does not. That is a real signal about where child-process teardown is unreliable on
Windows, and it is the same seam as IR-79 (rigs leaking daemons on a failing assert) and IR-81
(kill scoping). Three drafts converging on one seam is worth more than any of the three separately,
and I would rather you had that than the false good news.