deployah — INTAKE CLEARED at the handoff sha ed8ecd94, re-derived in my own gate. Then I read the
traces and there is a finding in them that is not in the handoff summary. Nothing armed.

## Intake (all re-measured here, none taken from HANDOFF.json)
- origin/diag/294-sync-stages = ed8ecd94a8a610815d5c2d6b54d3ed0f9d789d56, local tip identical. PUSHED.
- a9e786b2 IS an ancestor; tip adds EXACTLY TWO commits (ef9c1599, ed8ecd94); 5 files, +570/-58.
- Files touched are five crates/spt-daemon paths ONLY — no workflow, no registry, no release file.
- treqs: 0 stage tags and 0 "REQ-" over 570 header-excluded added lines; registry untouched. The
  detector control still returns 1 on 0dc977fa, so the zero is a reading, not a silence.
- PATCH IDENTITY PROVEN, not asserted: sha256 of both bundle copies of instrumentation.patch ==
  sha256 of my own `git diff a9e786b2..ed8ecd94` == 1a752dcda64a486ff72ff2d45ab030d8c51f429946f806eed1c5430ecaf3a23b.
  The preserved instrument IS the tree that ran.
- Candidate unmoved: core#218 OPEN head a9e786b2; golden/crossnode-294-r2 a9e786b2; origin/main de5a44bc.
- Both attempt2 legs: exit 0, exactly ONE Summary each, subject.sha = ed8ecd94 on both platforms.

## THE FINDING: the instrument covers ~6% of the Windows cell
Windows cell PASSED at **90.946s** and nextest flagged it `SLOW [> 60.000s]`. Linux: **1.085s**.
Same test, same sha — **83.8x**.

The IR294 event span on Windows is 90.348s. I gapped consecutive events; the three largest are all
in UNHOOKED regions:
  40.734s  broker.identity -> first pull.identity   (broker/serve/connect/dial setup)
  25.115s  poll.success    -> next pull.identity    (between exchange 2 and 4)
  18.757s  poll.success    -> next pull.identity    (between exchange 4 and 6)
  = 84.606s, **93.6% of the span**. Every hooked stage together is the other 6.4%.
Linux has the SAME SHAPE at 1/100 scale: 0.442 + 0.254 + 0.177 = 0.873s = 85% of a 1.031s span.

So the fork this instrument was built to decide — spawn-dominated vs visibility-gap-dominated —
is being decided inside the 6%. On the platform where the red lives, the bulk of the cell is
somewhere the hooks do not look. I am NOT proposing a cause; I am saying the denominator of the
attribution is smaller than it looks, which is todlando's call to make.

## Margins, since that is the point of all this
Windows polls: 175/400 (4.4197s), 46/400 (1.1432s), 7/400 (0.1531s). First pull consumed **43.75%
of the acceptance budget while PASSING** — 225 iterations of margin left. Linux: 5, 2, 2 of 400.
Of the Windows first poll's 4.4197s, sleep is 4.3975s and IPC 0.0218s — the poll costs almost
exactly its own 25ms sleeps; per-poll IPC is 0.5% and is not the thing to shave.

## Two things I would not want read the wrong way
1. **NO NATURAL EXPIRY WAS REPRODUCED.** These are numbers from PASSING executions. A non-repro is
   not an absence of the defect, and nothing here locates the red's cause. Finding 1 stays
   unclassified as to cause on my side.
2. The continuation controls' "late row observed with 29.9745s of 30s remaining" is a CONSTRUCTED
   late write — the control's writer sends only after the expiry signal fires. That number measures
   the control's own plumbing (~25-26ms), NOT how late a natural visibility arrives. It proves the
   acceptance is not rescued by lateness, which is what it was built for, and nothing about the wild.

## What I think the next measurement is (doyle's call, not mine)
One instrumented Windows pass tells us as little as one bare green did — that is exactly the 7.66
lesson. The cell passed at 90.9s here while the CI red FAILED at 55.7s, so wall time alone does not
sort pass from fail. **N repeats on this box at ed8ecd94** would give the first distribution we have
had of the first-pull poll (175/400 is one draw) and would say whether the 40.7s setup gap is stable
or the variable one. hertz released his pools and reports both boxes free, so I can take his lane's
pool over SEQUENTIALLY (claim from that worktree, loudly) instead of paying a cold build.
Say the number and I will run it; say no and the gate stays idle.

Release HELD, candidate unmoved, no gate arm, no CI dispatch.