V9 PINNED - two hunks, command-argument construction only. V8 IS UNTOUCHED (21ded908... re-measured), as are v7, v6, v5 and all five helpers.

PIN
  fp-driver-v9.sh  sha256 a9510e1ec86a71266b7f421b90a6a02c5c0f7586f96803c6843133b5b2b0bb12
  path C:\Users\decid\AppData\Local\Temp\claude\C--Users-decid-Documents-projects-spt-core\291081e5-a375-43ea-81a8-f0e1b7e15a41\scratchpad\fp-driver-v9.sh
  71890 bytes, CRLF throughout (1139/1139/1139), zero control bytes outside CR/LF/TAB, bash -n clean.
  handoff_request block is BYTE-IDENTICAL to v8's - lines 303-343, sha256 3aa9c6577c0597b5fca0b9fe8cb9571f62f11c7f06e025c5bf566c56c05d4f00 - because the change is entirely in the two callers. Your v8 block pin carries over unchanged.

THE TWO HUNKS
  :442   "env -u SPT_INSTALL_NO_FIREWALL SPT_HOME=\"$H\" \"$EXE\" serve lan --stop"
  :1063  "env -u SPT_INSTALL_NO_FIREWALL SPT_HOME=\"$H\" \"$EXE\" serve lan --bootstrap --port $PORT"
Nothing else in the diff. $PORT is left bare deliberately: it is the numeric 29470 set at :174, not a path.

MEASURED, with spaces in the EXECUTABLE, the HOME and the CAPTURE path simultaneously, driving the extracted v9 function with the v9 callers' own verbatim bytes (I extracted the caller lines rather than retyping them):
  v9 setup and teardown: exit 7 PRESERVED, both declared capture files written, markers present.
  v8 same arms, same rig: exit 127, "env: 'e/fp': No such file or directory", both declared files ABSENT. The space split exactly where predicted.
  And the argv/environment assertion you said you would make, which I agree is the real test: the stub received ARGV_COUNT=5 with serve / lan / --bootstrap / --port / 29470 as five separate arguments, SPT_HOME arrived WHOLE including its space, and SPT_INSTALL_NO_FIREWALL read UNSET even though I had exported it - so env -u still works through the quoting.
  EXECUTOR COMPETENCE, stated because my first attempt was a dead instrument: I initially ran the commands under env -i, which strips PATH, so env itself was not found and BOTH v8 and v9 returned 127 - a clean false negative that would have read as "the fix does not work". Caught by a positive control on a space-free stub that must return 7. Every number above is from the re-run where that control passes.

HERTZ'S CORRECTION IS RIGHT AND THE CAUSE IS WORTH NAMING. The handoff_request block is 2086 BYTES, not 2084. My hash was computed over the ENCODED bytes and is correct; my size line printed len() of a decoded Python string, i.e. CHARACTERS. The block contains one em dash, 3 bytes for 1 character, so character-count undercounts by exactly 2. A correct hash beside a size in the wrong unit is worse than no size, because the agreeing hash lends the wrong number credibility. Byte counts from here are measured on the encoded bytes.

hertz: your executor design is the right one - deleting the declared files first so their presence can only come from the command, and keeping unredirected output in a terminal log that never feeds a declared file, is what made the v7 teardown mode (exit 7 preserved, captures absent) distinguishable from the v7 setup mode (unrunnable, probe never ran). My arms above are supporting evidence on extracted bytes and do not stand in for your cases against the whole pinned driver.

Still unexercised and I am not treating any of it as done: the five-condition teardown verdict with real captures, request/receipt/census ordering beyond arm 2, and the signal case, which has never run on any version. No build, live probe, product execution, or elevation here.