FIELD PLAN, 85f84d73 repaired candidate. Source-only, nothing run, no window sought. One BLOCKER up front because it decides the plan's shape.

BLOCKER: THE ESTABLISHED DRIVER'S BYTES ARE GONE. attempt-2's stdout records driver_sha=d3891b096422e040..., and no file on this box hashes to it. Search scope, stated so you can judge the negative: every *.sh under .spt\preserved to depth 3, and every *driver*.sh / fp-*.sh under all 135 session scratchpads to depth 3, plus CRLF and LF variants of the closest candidate. What EXISTS is fp-driver.sh at 177ae8e251ff284d -- the as-reviewed variant, preserved at .spt\preserved\hertz-fp-driver-review\fp-driver-as-reviewed.sh and duplicated in two scratchpads -- plus v5 through v9 at five other distinct hashes, none matching. So "use the established driver" cannot be satisfied literally. Three ways out, your call: (a) adopt 177ae8e2 as the driver and record in the receipt that it is NOT byte-identical to what ran attempt 2, with a read-through for behavioural deltas before use; (b) reconstruct from the attempt-2 stdout's phase sequence, which is fully legible; (c) you rule 177ae8e2 the established driver going forward. I recommend (a) with (c) as the standing consequence -- reconstruction invents a third artifact nobody has reviewed.

SUBJECT UPDATE, smallest necessary:
- SUBJECT sha 53d625cd -> 85f84d738fa702f35c83910f314aae17849d125c; windows.rs blob c28874ef -> 848a23fe18e5ca819774f9881ef13504221992f3. Worktree .worktrees\304-w2-repr is already detached there, clean, and hertz's gate left it untouched -- HEAD, both refs, tree and the old release exe all verified after their run.
- Binder-check want= path is unchanged; same worktree, same target.

PROVENANCE UPDATE, and this is the part that cannot be skipped: the old exe edd3d8e0 DOES NOT CONTAIN THIS REPAIR. It was built at 03:36 from the pre-repair tree. So the field run needs a NEW release build, and every provenance value derived from it is new:
- cargo build --release in that worktree, which OVERWRITES target\release\spt.exe. That is safe now and only now: the old artifact is preserved with verified content at .spt\preserved\attested-304-w2-repr-20260912\ (full 64-hex digests, ok=True on all three files), cross-referenced to the attempt-2 receipt that attests it.
- A NEW signed set: keygen -> new seed and pinned public (attempt-2's pinned public 129c06bd... does not carry forward), rollout-build, mark-applied.
- PROVENANCE_THREE_WAY re-established at the NEW sha: exe == staged == signed_metadata. edd3d8e0 must appear NOWHERE in the new set; if it does, the run is measuring the old binary.

FOUR OUTCOMES, KEPT SEPARATE as you required -- no single verdict may absorb another:
1. Bootstrap enforcement codes. The gate stays == exactly [1]. Not widened, not softened to a membership test, and a UInt16 1 is the only success element.
2. Successful reconciliation. Its own outcome; a correct enforcement read does not imply a reconcile happened.
3. Registered populated timing. STILL UNANSWERED -- arm B has never run; attempt 2 stopped at ARM_B_SETUP_NOT_ACCEPTED (face unverified-after-write, enforcement=1), which is the refusal the repair addresses, not a timing measurement.
4. Actual reachability. Separate again; a rule that verifies is not traffic that arrives.
And explicitly: the repaired representation DOES NOT clear the prior {ProfileInactive, NoLocalUser} statuses. That mapping is still unresolved on this host -- the class exposes ValueMap 0..25 with the Values qualifier ABSENT, so no code has a derivable name. Never assert one, and do not let a green enforcement read imply those are explained.

GATES the driver already carries and that I would keep unchanged: 96 GiB capacity floor with the 32 GiB hard stop, checked before EACH producer; CI axis; box gate; GUARD baseline and post-phase comparison on the 5470 rule; teardown verified on the four conditions rather than asserted. I would add the GitHub queue axis explicitly, since you ruled my two local axes were both local.

BUILD ESTIMATE: UNKNOWN, and I will not manufacture one. What I have: the release pool is 1.3 GiB with 401 rlibs in deps, last written 03:36, so it is warm -- but the repair is in spt-daemon, so spt-daemon and its dependents recompile and spt.exe relinks, and I hold no measurement of that shape on this box. Hertz's 46 s (39 s compile, 0.427 s execution) is a DEBUG targeted lib lane and they said themselves it must not drift; borrowing it would be the same error as the whole-CI wall you already refused. Proposal: run the build under the 600 s external bound you set, with capacity re-checked immediately before it, and record the result as the first measured figure for a warm release rebuild of this subject.

NOT REQUESTED: no field run, no elevation, no build. This is the plan and the estimate you asked for before execution is requested.