BOTH CORRECTIONS TAKEN, and liam's answer found a DEFECT IN MY DRIVER that would have timed out the run with liam sitting idle. Verified in my own source before reporting it. Nothing built, nothing run, nothing elevated, no edit to the frozen set.

1. THE SECOND AXIS, job-level, from spt-bs-core. You were right that listener-vs-worker is one local-process axis.
   Registered runners, GitHub's own view: total_count=2
     id=3 hfenduleam  Windows  status=online  busy=false  labels=[self-hosted,X64,Windows,hfenduleam]
     id=2 kitsubito   Linux    status=online  busy=false  labels=[self-hosted,Linux,X64,kitsubito]
   Workflow queue: ZERO runs in queued, ZERO in in_progress.
   So axis 2 (what GitHub thinks: both runners online and not busy, nothing queued) agrees with axis 1 (what the box shows: listener present, worker absent). Both are samples, not reservations, and the post-merge re-occupation caveat still applies to the local axis.

2. A DEFECT IN fp-driver-v9.sh, found by liam's availability answer rather than by any test. liam is NOTIFICATION-DRIVEN: they wake when an spt message lands on their perch and they do NOT watch the filesystem.
   I checked my own source rather than taking it on trust. handoff_request ends with the request redirect, then a record line naming seq/nonce/req, then return 0. That is ALL. There is no spt send, no api call, no notification of any kind anywhere in the driver; the only other mentions of liam are a comment and the wait constant. The driver writes a request FILE and then waits 900s (300s in cleanup) for a receipt from an agent who will never be told the file exists.
   So the handoff is STRUCTURALLY INVISIBLE to its only recipient, and the outcome is not a stall: the cleanup wait times out and bootstrap-owned firewall rules are left possibly in place with the state marker deliberately set. Same family as the two defects already fixed this lane - something assumed to reach a consumer that structurally cannot reach it.
   A revision would need: the emit step ALSO spt send liam with the command text in the body, and - liam's requirement, which I think is the stronger half - a PING/ACK BEFORE the clock starts, because delivery to them is not guaranteed-visible (their perch registration was AUTH_REFUSED at SessionStart, they are reachable only through a separately-raised Monitor listener, and tag-borne bodies ride an inject leg that can swallow silently). Do not treat SENT as SEEN. I have NOT written that revision: v9 stays frozen until you authorize one, and I am not touching it meanwhile.

3. LIAM'S ANSWER, relayed with their labels. They marked what was measured just now versus derived, and ran nothing.
   MEASURED: elevated=True as HFENDULEAM\decid, same elevated session as A7 actions 1 and 2, so NO UAC hand from the operator; 29470 clear with no listener; 5470 still pid 4732 unchanged; the a7 rig daemon pid 40280 is reaped and a7-home quiet; the mint path has been OPEN since 2026-07-26 and gates Request FILING, not elevated execution, so it is not a blocker.
   TIMING, derived from their two real A7 actions rather than estimated: action 1 landed 06:27:41, report out 06:30:11 = 150s INCLUDING ringing you for scope plus a sha256 over a 38MB exe, a git log and a netstat; action 2 landed 06:31:33, report out 06:33:04 = 91s with scope pre-granted. Request-seen to receipt-existing is roughly 30-60s with scope in hand, because most of their wall time is verification around the command, not the command.
   THE 300s CLEANUP RISK IS THE SCOPE ROUND TRIP, and it is yours to remove: if BOTH commands, setup AND teardown, are granted in your own words BEFORE the run starts, they need zero round trips and the receipt exists inside a minute. If teardown scope is only settled at cleanup time they will ring you rather than run unscoped, and that trip is what eats the 300s.
   THEIR REACHABILITY DIES WITH THEIR SESSION. They cannot promise a future window: the listener lives as long as their Claude Code session and a clear, compact or harness restart ends it with no signal on my side. Their fix: re-ping immediately before the driver starts. There is no schedule of unavailability, only alive or not.
   ON STANDBY THEY COMMIT TO: no long-running foreground work, so never more than seconds from seeing a message; product verbs only, absolute exe path, SPT_HOME set explicitly inside the elevated process, all streams redirected to file and never piped, no netsh, no hand-written rule, no other listener touched, stop-and-report on any unexpected port or binder.

4. YOUR OTHER CORRECTIONS, accepted without argument.
   Cold-release duration and footprint are UNKNOWN and the workflow totals are NOT bounds on that build. I will not quote them as bounds again; they are evidence about a workflow on a runner and nothing more.
   The 122.09 GiB free sample is preserved as a sample with its timestamp, and the per-producer capacity checks stay exactly as the driver has them (capacity_gate before each producer, floor 96, hard stop 32), so a footprint that eats the 26.09 GiB headroom refuses at the NEXT producer rather than silently continuing.
   #300: the submitter interpretation is NOT settled and awaits Reavo's confirmation via lia. I have marked it provisional and will not build on it; perri's co-authorship objection stays OPEN rather than retired, the previous-commit interval is not adopted as proof, enqueue-versus-dequeue stays unresolved, no measurements requested, and the contract draft is untouched at 24069979, unpushed.

ADMISSION remains held, and the blocking list is now: (a) shim_unresolved=2 at the box gate, yours to rule or another agent's to clear; (b) the cold-release footprint against 26.09 GiB of headroom, unmeasured; (c) the file-only handoff defect in item 2, which needs a revision I have not written; (d) pre-granted setup AND teardown scope in your words, which removes the 300s risk; (e) a re-ping of liam immediately before any start, because their reachability cannot be promised forward.