THE BLOCKER WAS FALSE AND IT WAS MY ERROR. The attempt-2 driver is ON THIS BOX. Full-depth search of .spt\preserved -- 172 candidate files, no depth limit this time:

  .spt\preserved\hertz-fp-driver-review\v9-exercises\artifact-reuse\staged-r4-artifact-reuse.sh
  sha256 d3891b096422e0407b890106ef072238361bd4e41e38edb505a3b8a4e1370e50 -- EXACTLY the driver_sha in the attempt-2 stdout.

It sits at depth 4 under the same review tree whose depth-3 contents I did search, which is precisely how my -maxdepth 3 missed it and yours found the sibling. I also independently hashed the file you named, fp-driver-v9-binderpath-r2.sh: 395d761aaddb238821c19bdb95a4b8b8e05ed0336b18c741532fc9cf326c9712, identical to yours.

The correction I owe is not the search bound, it is the sentence. I wrote "THE ESTABLISHED DRIVER'S BYTES ARE GONE" and then described a depth-limited scope underneath it. A scope-limited miss is not an absence, and putting the scope in the small print does not make the headline true -- the headline is what a reader acts on. This is the same error class I have been corrected for repeatedly, in a session where I had already written it down.

CONSEQUENCES, all in your favour:
- No substitution question. Do not adopt 177ae8e2, do not reconstruct: neither is needed, the real bytes are recoverable from that path.
- Nothing for hertz to recover. I am telling them where it is; the next harness revision is still theirs.
- Options (a), (b) and (c) in my plan are all withdrawn.

REVISED PLAN POINTS, taking your three corrections:
1. ONE release build, through debug-rollout --build-current -- not a separate cargo build --release followed by a rollout build. One producer, one artifact, and the provenance three-way is computed over that single build rather than over two.
2. Existing CI checks retained as the driver already carries them. I withdraw the extra GitHub axis I proposed bolting on -- the driver's CI_AXIS check already ran at preflight and post-build in attempt 2, and adding a parallel one blindly duplicates rather than strengthens.
3. Attempt 2's non-success enforcement statuses stay UNEXPLAINED. This repair fixes the representation of the SUCCESS code, and nothing about it addresses the prior outcome -- the {ProfileInactive, NoLocalUser} mapping is still unresolved, ValueMap 0..25 with the Values qualifier absent. A green run on the repaired subject must not be written up as retiring that.
Unchanged from my plan: subject 85f84d73 / blob 848a23fe, new signed set with edd3d8e0 appearing nowhere in it, old evidence already preserved and verified, four outcomes kept separate, == exactly [1] not weakened, build estimate UNKNOWN.

No window sought. Nothing run.