END. DRIVER_EXIT=2 (VOID) at trial a-1. LAUNCH 10:26:16Z, FINISH 10:39:48Z. Cleanup ran, pool released, 5470 untouched, one cleanup failure and one named residual.

THE VOID IS A FALSE NEGATIVE AND THE DRIVER'S OWN CAPTURE REFUTES ITS OWN VERDICT. This is a defect in v9, not a product result, and I am not dressing it up as one.
  The verdict: "a-1: the listener on port 29470 is not the built executable (...) - wrong binder, so the trial measures another process".
  What the driver itself captured in portfields-29470-a-1-up.txt: LISTENER_STATE READ, LISTENERS 1, OwningPid=49768, Path=C:\Users\decid\Documents\projects\spt-core\.worktrees\304-w2-repr\target\release\spt.exe - which IS the built executable.
  The predicate, v9 line 925: grep -q "Path=$EXE" where EXE='C:/Users/decid/.../target/release/spt.exe' with FORWARD slashes, against a capture that writes the Windows form with BACKSLASHES.
  Measured both ways: raw match FALSE, separator-normalised match TRUE. The predicate cannot pass on this platform - it is not a strict check that found something, it is a check that can only ever fire.
  So a-1's wall is void for the stated reason ONLY as a consequence of the comparison. The product did what it should: a-1.out carries LAN_BOOTSTRAP_UP on 29470 and sha256 edd3d8e0..., the same hash as the three-way provenance.

WHAT SUCCEEDED AND IS NOW MEASURED, including two numbers that were unknown when you granted the window:
  THREE-WAY PROVENANCE OK - exe == staged artifact == signed metadata artifact_sha256, all three edd3d8e0566690493182a0e1807b1a6b43c52cff45511b9e81490e256dd10e21. s3_rollout_EXIT=0, s4_applied_EXIT=0, s5_prov_EXIT=0, s5_meta_parse_EXIT=0.
  COLD RELEASE BUILD DURATION, measured from the evidence files' own timestamps rather than estimated: capacity-rollout-build.out at 10:27:08Z to s3-rollout.out at 10:36:13Z = 9m05s, at CARGO_BUILD_JOBS=2. That is one build on one box and it is not a bound on any other.
  FOOTPRINT, also measured: the lane target tree went 8.7 -> 9.9 GiB and total disk growth across the whole run was 1.25 GiB (free 122.08 -> 120.83 GiB). Nowhere near the 64 GiB growth stop or the 32 GiB floor; the 96 GiB producer floor held at every capacity_gate and every gate recorded 122.08.
  POST-BUILD GATES: CI_AXIS ok (no non-terminal runs), BOX_GATE ok with r3 (cargo_build=0 runner_descended=0 shim_unresolved=0, analyzer=6 recorded not gated), GUARD_UNCHANGED post-build - 5470 rule fields and listener identity identical.
  ARM A precondition measured: owned pair ABSENT. Arm B never began, so no setup handoff was ever emitted - liam was never asked for anything and nothing elevated ran. No firewall mutation state was ever marked.

CLEANUP EVIDENCE, every step ran:
  listener: cleanup_stop_LAUNCH=OK cleanup_stop_EXIT=0, and port 29470 is now CLEAR - no listener (measured after the run).
  firewall: CLEANUP_SKIP - fw_mutation_may_have_occurred was never marked, so there was nothing owned to remove. GUARD_UNCHANGED final-post-cleanup: 5470 rule fields and listener identity identical to the baseline. The production port was never disturbed.
  secret dir: removed.
  pool: RELEASED. pool_release_EXIT=0, and the verb's own words: "pool ... released (still owned by C:\Users\decid\...\.worktrees\304-w2-repr)".
  ONE CLEANUP FAILURE, reported and not forced: rig_daemon_stop_EXIT=3. cleanup-failures.txt carries it with its timestamp. The refusal is the PRODUCT's, verbatim: DAEMON_STOP_REFUSED - a broker-stopping command is never run by an spt endpoint while OWL_SESSION_ID is set, and no flag overrides it including --force.
  CLEANUP_END steps_failed=1 original_rc=2, and the driver correctly kept the VOID as the owning finding rather than letting the cleanup failure replace it.

THE RESIDUAL, named rather than left for someone to find: pid 49768 is still running - C:\...\304-w2-repr\target\release\spt.exe daemon run --detached, started 10:38:36Z. It is the RIG's own daemon, running the BUILT binary, and it holds target/release/spt.exe open.
  The cause is not a surprise and not a new defect: v9's cleanup step 3 deliberately leaves OWL_SESSION_ID intact, with the comment that clearing it would bypass a refusal guard you have not approved, and that a refusal is REPORTED and nothing is force-reaped. The driver inherited OWL_SESSION_ID from my session's environment, so the product refused to stop even the rig's own isolated daemon. That is the ruled behaviour doing exactly what it says.
  It is my run's process and therefore mine to clear - but it is also part of this run's state, and the window is yours to close. I have NOT touched it. Say the word and I clear pid 49768 by path-matched identity only; it also matters because a live process holding target/release/spt.exe will block a later rebuild of that exact file.

NOT REACHED, so nothing about them is claimed: trials a-2 and a-3, the elevated setup, Arm B and all three of its trials, the five-condition teardown verdict, and D1 capture. The VOID stopped the investigation by design - no further trial runs - and I did not retry anything, weaken any predicate, bypass any guard or change the subject.

MY RECOMMENDATION, which is a recommendation and not an action: v9 needs a separately hashed revision fixing line 925 to compare paths without assuming a separator form, and the same question should be asked of every other predicate in the driver that matches a captured Windows path against a configured forward-slash one. I have not written it and will not until you authorize.