Both focused controls DONE. Native outcome on frozen bb417192 first, because it found the gap you predicted, then the fix and the re-run.

NATIVE OUTCOME ON FROZEN bb417192 (declined setup: markers SET before dispatch, executor NOT_STARTED)
  k1a/k1b stop gate, resources measured absent: PASS - NOT_NEEDED, no autostarting stop.
  k1c NO removal dispatched: FAIL - HANDOFFS=1.
  k1d dispatch state: FAIL - DISPATCHED, not NOT_NEEDED_MEASURED_ABSENT.
  k1e disposition: FAIL - empty.
  k2a/k2b unreadable arm, stop withheld and nothing spawned: PASS.
  k2c/k2d unreadable arm, no dispatch + PENDING: FAIL - dispatched anyway.
  k3 positive control (rules PRESENT -> dispatch): PASS.
  L (the remover run, partial failure): PASS 4/4.
  So the LISTENER gate already measured before acting; the REMOVAL dispatch still fired on the marker alone - IR-124's mistake one step over. That is the native outcome you asked for.

THE FIX, and the new pin
  NEW  d2/fp-driver-d2.sh  99df52c3b6ff234b27e127288ab02c3a5a764f9f3268441845a6e68b2a466ecc
  DIFF d2/fp-driver-d2-bafed7a7-to-99df52c3.diff  3903ba59... (7 hunks, +234/-25)
  RECEIPT d2/d2-pinned-removal-receipt.md f1180269fb18a09a7078b769d22012a0460d7e1a20d7447445463deb839907e6 (addendum appended, original sections unchanged)
  removal_check now takes a TAG and runs TWICE: pre-teardown and post-teardown, separate transcripts and separate records. The pre reading gates the dispatch in the shape of the listener gate - the marker decides whether the question is ASKED, the measurement decides whether a command is REQUESTED. CONFIRMED-absent -> NOT_NEEDED_MEASURED_ABSENT, verdict NOTHING_TO_REMOVE, no dispatch. UNREADABLE* -> WITHHELD_UNREADABLE_STATE, PENDING, no dispatch and nothing spawned. Anything present -> verify the pin, dispatch once.
  NOTHING_TO_REMOVE is a TERMINAL MEASURED state added beside VERIFIED in the final verdict rule. It still has to clear the same two other facts - no residual process of this home, no listener still bound - either of which forces PENDING exactly as before. Flagging that because it touches the final verdict conjunction.

CONTROLS ON 99df52c3
  d2/rig-d2/declined-setup-controls.sh afa26b7b... -> declined-setup-controls.out ba860e9b..., 16/16.
  d2/rig-d2/cleanup-controls.sh 22c142e8... -> cleanup-controls.out 28f84f4c..., 49/49 (re-run because this change touches the code those controls cover - not an unrelated suite).
  d2/rig-d2/payload-partial-fixture.ps1 27f627ae..., 6/6: the REVIEWED DECODED PAYLOAD 46c76fae... is RUN under shadowed Import-Module / Get-NetFirewallRule / Get-NetFirewallPortFilter / Remove-NetFirewallRule over a hashtable store. First removal succeeds and mutates the fixture; the SECOND THROWS. Failure preserved verbatim: "removal of spt-core-bootstrap-inbound-tcp-lan failed". One owned rule gone, one REMAINS, in both fixture stores. The ACTUAL probe then reads that state - two ABSENT, two PRESENT, both per-store controls alive - and removal_check classifies it PARTIAL -> PENDING with NO retry. The host was never read or written.

NO-RETRY / NO-SPAWN observations, explicit: HANDOFFS=0 on every refusal arm (k1c, k2c, l2); no cleanup_stop command reached the run_cmd stub in either declined arm (k1b, k2b); the PARTIAL path issues no second dispatch; a nonzero remover exit keeps the verdict PENDING (l3).

DISCLOSURES, mine not the subject's
  Three harness defects: (1) the new control file first loaded only removal_check, so teardown_pin_verify was command-not-found and K1/K3 measured the HARNESS - a missing definition reads exactly like a refusal; caught and fixed before I read any verdict. (2) cleanup-controls had no pre-teardown transcript, so the new gate withheld and seven controls went red - harness fault, not subject. (3) section G's extraction started mid-if-chain once the gate moved the chain's first line.
  One process slip: bb417192 was NOT snapshotted before it was superseded, against this lane's convention. Reconstructed by reverse-applying this change and re-assembling; the result hashes EXACTLY bb417192, so history/fp-driver-d2-bb417192.sh is proven rather than asserted, and the tree was restored to 99df52c3 and re-verified.

CONTROL-PROCESS DISPOSITION: two pwsh processes across the two control files (the probe fixture harness and the payload fixture harness), both shadowing every NetSecurity command; everything else is this harness's own shell. No host query, no rule read or written on this host, no elevation, no field execution, no kill, nothing signalled. Scratch dirs removed on exit by trap; transcripts copied out first.

The diff is ready for your source review. D2 GO remains yours.