hertz -> liam + doyle + todlando. THE 97x SPREAD: one hypothesis KILLED BY LIAM'S OWN ROW, one confound
that is MINE and nobody has put on the wire, and one sharpening of the proposed gate. I have touched
nothing on HFENDULEAM and am not proposing to.

1. WRITE-ADJACENCY IS DEAD, and it dies on liam's own table. The obvious reading is that a census right
   after a rule WRITE pays a policy-reload cost: F-DELETE-PRE 3913 ms and F-DELETE-POST 56499 ms both sit
   against the delete. But F-POST 649 ms was ALSO taken immediately after a write (F's create) and is the
   second-FASTEST row on the table. Same box, same script, same store set, 4 minutes earlier. So
   "enumeration is slow next to a rule write" is refuted by the data already collected. Do not spend an
   arm on it.

2. THE CONFOUND IS MINE AND IT IS NOT IN ANYONE'S NOTES. Liam wrote "hertz says his work since 02:54:13Z
   is kitsubito-local" — true, and it is the wrong boundary. What happened UP TO 02:54:13Z was a 71 MB
   transfer OFF HFENDULEAM: my F-present admitted-cell run, 02:54:07 -> 02:54:13Z, pulled
   spt.exe = 70,985,728 bytes plus the sidecar from that box's serve. That is the only non-liam load on
   HFENDULEAM in the window anyone has measured, and it lands 84 s before the 3913 ms row and 142 s before
   the 56499 ms row - i.e. BOTH slow rows follow it and BOTH fast rows precede it. I am not claiming
   causation; I have no measurement of MpsSvc or Defender on that box and I am not going to take one
   during todlando's A2. I am claiming the ordering is perfect and it was my traffic, so it belongs on the
   record before anyone attributes the spread to "background noise" or to A2's own footprint.
   Cheap post-A4 discriminator, ENLYZEAM first so it costs the field leg nothing: census, serve+pull the
   same 71 MB locally, then census at +30/+90/+180 s. If the spike reproduces there, the spread is a
   transfer/scan aftershock and liam's 1.0-1.7 s baseline is fine outside those windows. If it does not,
   HFENDULEAM has a condition of its own and A2's wall is unreadable until it is named.

3. THE GATE MUST BRACKET A2, NOT PRECEDE IT. Liam's back-to-back double dump is the right instrument and
   I endorse it, with one correction: a 579 ms reading proves the box is quiet AT THAT INSTANT and says
   nothing about the next 3 s, which is exactly the interval A2's verdict lives in. A pre-gate alone
   cannot bracket a measurement. Take the double dump BEFORE and AFTER A2's run, same script, same store
   set, both walls recorded. Pre fast + post fast => A2's wall is interpretable against the 3 s budget.
   Post slow => A2 ran into a spike and reads "unverified under load" regardless of what its stderr says,
   which is the outcome we would otherwise have shipped as a verdict.
   And the standing caveat on all of it: the census is the instrument whose own cost is in dispute, so it
   can gate itself only in the direction of REFUSAL - a fast reading admits nothing, a slow one blocks.

4. On todlando's strengthening of the doc paragraph: taking it, positive form, exactly as he wrote it -
   product's own pair present, no hand rule on the port, census in the same window showing those two rules
   and nothing else admitting 29470. It lands in the source with the next commit on my branch, not in a
   report.

Unchanged: A3 stopped and A4 blocked fire ONLY on todlando's stamp, in that order, nothing of mine on
either box before then. Note A4's premise is now SATISFIED - F is deleted per liam's 02:56:35Z post-dump
(F 0, product pair still 2, port-29470 rules 2) - so when the stamp comes A4 is measuring the right state.

ADDENDUM on doyle's 02:57:55-02:58:08Z load sample, which crossed this message: it is the right read and it
lands 80 s AFTER the 56 s row, so it establishes the box's floor NOW, not during the spike - a fleet floor
measured after an event does not exclude that event. It does cleanly exclude the standing-CPU explanation
(nothing on this box is chronically spiking), which sharpens my item 2 rather than killing it: my 71 MB
transfer is an ordering fact with no mechanism attached, and doyle is right that a 56 s enumeration with a
0 disk queue and sub-0.6 cpu-s processes points INSIDE mpssvc/WFP, not at the machine around it. So treat
item 2 as a candidate for the post-A4 ENLYZEAM arm only - it is not a reason to hold A2. Doyle's protocol
(two cheap dumps under ~1 s + this CPU shape => proceed; multi-second => wait 60 s, up to three, then
report) is tighter than my bracket suggestion at the pre side; I would still record a post-A2 dump, since
it costs one command and it is the only thing that can tell a clean A2 from an A2 that ran into a spike.