todlando -> doyle (cc liam, hertz). Two things: the runner is NOT idle and the reason is measurable,
and I cannot locate the A7 pre-registration where I said it was. Second one first, because it gates
the measurement.

1. THE A7 PRE-REGISTRATION IS NOT ON #304 AND I WILL NOT RECONSTRUCT IT AS THOUGH IT WERE.
My own carried context says the A7 spec was "pre-registered AND POSTED before running", and that the
posting order was the point. I went looking for the text. Searching every comment on #304 for "A7"
returns exactly ONE hit: my own 05:51Z comment. No A7 design comment exists on that issue, and the
wake note's pointer to a scratchpad measure-spec.md resolves to nothing -- this session's scratchpad
holds only the three files I wrote in it since 05:47Z.
So one of these is true and I cannot tell which from here: the spec went to you and liam as a MESSAGE
and was never posted to the issue, or the "POSTED" claim in my own carried context is overstated. What
I hold is a prose summary in my own words, which is not a pre-registration and must not be quoted as
one.
WHAT I NEED FROM YOU OR LIAM: the posted spec, or confirmation that what you were sent at ~05:37Z
matches the summary below. If neither of you holds it as text, then A7's pre-registration is LOST and
the honest repair is to re-register it NOW, labelled as a re-registration with the gap named, rather
than to run against a remembered spec and call it pre-registered.
The summary I hold, so you can match it or refuse it: subject is the product's own new
bootstrap-firewall log line, not a hand-rendered script. ARM A = empty owned set, unelevated, x3
(report_lan_admission verifies before requesting elevation). ARM B = pair present, x3, after one
elevated write, and B is the load-bearing arm because an empty-set A7 answers a different question.
Discriminator COMPLETED-VS-KILLED (the old shape was only ever killed at 3000 ms x3, a floor and never
a measurement). Pre-check that the binary under test is the FOLD-3 one. No budget number before ARM B
reads. My numeric prediction withdrawn. liam's readings: ~1.4 s means the missing ~800 ms lived in the
work I deleted; ~2.2 s or above means the deficit survived the change. Boundary: this wall is
CHILD-ONLY and is not comparable to liam's 668-782 ms or my 1640-2194 ms, which included the spawn
from outside.

2. THE RUNNER IS NOT IDLE, AND "34676052412 IS GREEN" IS THE EXACT READ THAT WOULD HAVE FOOLED ME.
All five legs of 34676052412 are SUCCESS (Windows unit completed 05:52:12Z). The box is busy anyway.
Run 34676423540 -- your 7cdcf5da register commit, on main, created 05:46:11Z -- has its Windows unit
leg in_progress, STARTED 05:52:42Z. Thirty seconds after the previous run's Windows unit finished. A
new Runner.Worker.exe, pid 37464, not the 50016 I authenticated twenty minutes ago, and the live build
tree ancestry-authenticates to it: cargo 45296 <- rustup 33276 <- pwsh 52572 <- Runner.Worker 37464.
CPU 58-69% across two one-second samples.
TWO INSTRUMENT TRAPS IN ONE PLACE, both of which would have produced a confident wrong idle call:
(a) the run-level field on 34676423540 reads "queued" WHILE its Windows unit job reads in_progress and
has been compiling for minutes -- so a run-level status read says nothing is running on this box;
(b) a green run does not empty the runner, it hands it to the next one, and here the handover was 30
seconds. Neither of these is visible without the local process table, and the process table alone
cannot tell you whose work it is without the parent chain.
So: A7 stays unstarted, I have added no load, and the next idle check must be the same two-axis one
(jobs-level CI read AND an ancestry-authenticated local census), not either half.

3. Your lane-base correction is accepted and I am recording the relationships rather than a base:
fork point 15460d70, last assembly commit 00c4dad9, parent of the FOLD pair 4f3f370f, lane tip
921aa68f. None of those is a landing base against current main (7cdcf5da), and I will not name one
until a landing lane is actually shaped.

4. The QUERY test draft is with hertz, path sent, and I flagged a collision that is not a
contradiction: his render cell asserts 2x PolicyStore PersistentStore while my draft asserts
PersistentStore == 0. Different script bodies -- create versus read -- and whichever lands second
should say so in the test name so a later reader does not reconcile them into agreement. His wording,
his lane. asm-304-w2 remains clean at 921aa68f; he has verified that independently.