HELD ON v8, NOTHING LAUNCHED AGAINST IT. Your hold arrived before any v8 run; the only thing I did to v8 was preserve and verify it, which is not a launch. There is no active command-test to interrupt.

v8 PRESERVED AND VERIFIED (frozen, sha256 -c clean)
  fp-driver-v8.sh  21ded908e2b2609b4ff3aa857d6d6dc7217d7a096e037b06fd670072c8fc59f1  = your pin
  71874 bytes, CR=1139 LF=1139 by tr -cd byte count
  five helpers byte-identical to the v7 set and to todlando's live fp-bin
  THREE hunks v7->v8 by my own diff -U0 count, and they are the three described:
    composition moved inside handoff_request after HO_OUT/HO_ERR exist, with quoted targets
    run_exactly emits cmd_exact instead of the caller's argument
    the setup caller drops its redirects; a fail-closed die refuses any caller that smuggles one
  handoff_request block, lines 303-343: 3aa9c6577c0597b5fca0b9fe8cb9571f62f11c7f06e025c5bf566c56c05d4f00, equal to todlando's block pin. One correction to his message: that block measures 2086 bytes here, not 2084 - the hashes agree, so the bytes agree and only his size line is off.

THE CAPTURE EXECUTOR YOU ASKED FOR IS BUILT, CONTROLLED, AND ALREADY PROVEN ON v7
It executes the request's run_exactly VERBATIM through bash -c and never writes the declared capture files itself - it deletes them first, so their later presence can only come from the command. Unredirected output goes to a terminal log that models the operator's console and is never copied into a declared file. The receipt is written by the executor, since recording the exit is the operator's duty. Probe stub emits distinct stdout and stderr bytes with a per-invocation token and a known NONZERO exit 7, so a stale file cannot pass as a fresh capture.

  POSITIVE CONTROL, a correctly-redirected request: 4/4 PASS, exit 7 preserved, terminal EMPTY.
  v7 SETUP:    exit 2, "bash: -c: line 1: syntax error near unexpected token `2'". The probe NEVER RAN. Both declared files absent. The setup handoff was not merely mis-redirected, it was UNRUNNABLE.
  v7 TEARDOWN: exit 7 preserved, but both streams landed in the operator's terminal and both declared files stayed absent.
Two distinct failure modes from one root cause, measured by execution rather than by reading, against a control that passes. Preserved with the exact paths exercised, terminal logs included.

ON THE SPACE ARM. todlando's warning reached me before I ran it, so it cost nothing: the redirects are quoted in v8 but the command half at :442 and :1063 passes $EXE and SPT_HOME=$H unquoted. When the new pin lands I will run spaces in the EXECUTABLE, the HOME and the CAPTURE path together as you require, and I will name which path carried the space in any failure, so an unquoted-command defect is never reported as a redirect regression. I will also assert the argv and environment the stub actually received, not just the files, since a space that splits an argument can still leave the captures looking right.

INSTRUMENT PINS
  exec-runexactly.sh        5063debbc934e6ebd956b8dbc6841a01e1ade11c6dc9caf06c992f037e341cd3
  make-poscontrol-request.sh 2517abd9cc687959e55704dd1e9908989161969a9f6f4044b9331be40bb4fb9c
  spt-stub.sh               14c84b0e04123d6371f15b377a7a73a4da9a0aa292b019a2fcece63d2211bf66
  make-stubs.sh             76cbed08d08727bc13d19913e13699dcf552dcc9ef9f13f040a66b240dff5316
  run-v7.sh                 b18e48d3ef2bac8949871c7a20b80ffd4d5e468d5580156758bf7c6dcaef9243
Your designated a8ed64e6 stub is preserved unchanged and separately; everything above is the working line, pinned apart from it as you instructed.

STILL UNEXERCISED, and I am not letting these drift into done: the five-condition teardown verdict with real captures, request/receipt/census ordering beyond what arm 2 showed, and the SIGNAL CASE, which has never run on any version.

Waiting on the new pin. No build, live probe, product execution, or elevation.