todlando -- W-0 REACHABILITY PREFLIGHT, END 2026-09-11T11:36Z. Open 11:31Z, ~5 min. No cargo, no build, no product mutation, no firewall change. FOUR arms ran; two were not in my START and I say so below.

THE SINGLE THREE-VALUE FACT: **BLOCKED-BY-HOST-FIREWALL.**
NOT BLOCKED-BY-ACL -- so the leg does NOT stop at your Q2. W-2 is schedulable.

RAW LINES, all four arms, each with its loopback positive control run FIRST.

ARM 1 -- live bootstrap listener, TCP 5470, pid 4732 = C:\Users\decid\AppData\Local\spt-core\bin\spt.exe. READ-ONLY, GET only.
  control  curl http://127.0.0.1:5470/install            -> http_code=200 size=322, exit 0
  peer     ssh reavus@kitsubito curl -m 8 http://100.68.35.65:5470/install
           -> curl: (28) Connection timed out after 8002 milliseconds
              http_code=000 size=0 connect=0.000000     (no handshake: connect never completed)

ARM 2 -- throwaway python listener, TCP 54701, binder C:\Program Files\Python312\python.exe.
  control  curl http://127.0.0.1:54701/                  -> 200, body "spt-w0-preflight"
  peer     ssh ... curl -m 8 http://100.68.35.65:54701/
           -> curl: (28) Connection timed out after 8002 milliseconds, connect=0.000000

ARM 3 -- NOT IN MY START. UDP 7470, INSIDE the existing rule "spt-ci two-host rig UDP-In (kitsubito only)" (RemoteIP 100.98.197.12/32, UDP 7460-7499). Same python binary as arm 2.
  peer     ssh ... printf 'w0-udp-probe' > /dev/udp/100.68.35.65/7470  -> SENT_OK
  here     UDP_RECEIVED from 100.98.197.12: b'w0-udp-probe'            -> IT ARRIVED

ARM 4 -- NOT IN MY START. UDP 9470, OUTSIDE that range. Same binary, same profile, same peer, same second.
  peer     ssh ... printf 'w0-udp-outside-range' > /dev/udp/100.68.35.65/9470 -> SENT_OK
  here     UDP_TIMEOUT no datagram                                            -> IT DID NOT

WHY I ADDED ARMS 3 AND 4 MID-WINDOW: arms 1 and 2 both failed, and my filed falsifier table said "both fail -> BLOCKED-BY-ACL". I did not take that. Both arms were TCP, so a two-TCP failure cannot tell a host-firewall drop from an ACL denial -- my own table was under-determined, which is my defect and not the box's. Arms 3/4 are the discriminator that table was missing, and they cost one ssh each.

WHAT THE FOUR ARMS TOGETHER ESTABLISH, in order:
  1. Packets from kitsubito DO reach this host (arm 3). The tailnet path is up and there is no blanket ACL deny toward this node.
  2. Admission is decided by the PORT+REMOTE-scoped rule: inside 7460-7499 a datagram lands, outside it the identical datagram from the identical binary does not (arms 3 vs 4).
  3. PROGRAM-SCOPED RULES ARE NOT ADMITTING TAILNET-INBOUND TRAFFIC ON THIS BOX. "Python" (Private, TCP+UDP, LocalPort Any, Program C:\program files\python312\python.exe) names exactly the binder of arms 2 and 4, and "spt-core daemon" (Private, Protocol ANY, RemoteIP Any, Program ...\spt-core\bin\spt.exe) names exactly the listener of arm 1. Every one of those three fetches was dropped. The Tailscale interface is NetworkCategory=Private (measured, Get-NetConnectionProfile), so profile is not the out.
  4. "spt lan-bootstrap 5470" could never have admitted this: RemoteIP 192.168.1.0/24, and the peer is 100.98.197.12. It is a LAN rule, and #297's report is a tailnet report.

PREDICTIONS AGAINST RESULTS, my refutations included and leading.
  P1 REFUTED, and squarely. I predicted the 5470 GET SUCCEEDS via the program-scoped "spt-core daemon" rule. It timed out. My reasoning -- rule names the exe, interface is Private, therefore admitted -- was sound in form and false in fact, and arm 4 is what shows the general mechanism rather than a one-off.
  P2 REFUTED, same mechanism, same reason.
  P3 REFUTED AS STATED but its CONSEQUENCE HOLDS BY ANOTHER ROUTE. I predicted ADMITTED. The verdict is BLOCKED-BY-HOST-FIREWALL -- and the thing P3 was actually for (does the ACL stop us at Q2) is answered NO by arm 3, which is a stronger instrument than the TCP success I had planned to infer it from.
  My START's falsifier table was itself wrong where it mapped "both fail -> BLOCKED-BY-ACL": both arms shared a protocol, so that row could never have earned its verdict.

THE LIMIT, stated so nobody cashes this further than it goes: arm 3 proves the ACL permits UDP 7460-7499 from kitsubito. It does NOT prove the ACL permits TCP 5470. The host firewall is therefore a MEASURED SUFFICIENT cause for the TCP failure; an ADDITIONAL ACL denial on TCP is NOT excluded, and I am not claiming it is. ONE measurement settles it: a port+remote-scoped TCP allow for the rig port, then re-run arm 2. That is exactly what the #297 product does at start, so W-1/W-2 answers it as a by-product -- I did not add the rule here because it is a mutation and your word was that nothing else starts.
  Also unmeasured: WHY program-scoped rules do not admit on this path. I measured THAT they do not. WFP's handling of the TUN interface and Tailscale's own filtering are candidates; I name none as the cause.

TWO THINGS THIS BUYS BEYOND ITS OWN QUESTION.
  (a) ADR-0059 Amendment 2's central claim -- port+remote scope is the thing that works, program scope decays -- is now MEASURED ON THIS BOX before a line of the product exists. The amendment argued it from the rebuild-hash orphaning story; arms 3/4 show program scope failing even when the path is exactly right.
  (b) FOR YOUR FORK (ii), a measurement and not a recommendation: the twohost_web QUIC hole's precondition is PRESENT for UDP 7460-7499 from kitsubito -- that rule exists, is enabled on Domain+Private+Public, and arm 3 proves it delivers. Whether that range covers the rig's actual ports is a check someone should run against the rig's port pair before assuming the hole is still open. Still not mine, still labelled, and a TCP verdict says nothing about it.

TEARDOWN, PROVEN. All probe processes exited on their own deadlines; I swept by COMMAND LINE (throwaway.py / udp_probe.py), never by process name alone. netstat after: NO LISTENER on 54701, 7470 or 9470. The operator's listener is untouched and still pid 4732 on 0.0.0.0:5470 -- same pid as at START, never stopped, never restarted, GET only.

IR-107, both boxes, both expecting and getting not-a-git-repository:
  HFENDULEAM C:\Users\decid\AppData\Local\Temp -> fatal: not a git repository (or any of the parent directories): .git
  kitsubito  /tmp                              -> fatal: not a git repository (or any of the parent directories): .git

POST-CENSUS, and the box is NOT free -- of the RUNNER, not of me.
  Zero survivors from this window. Zero cargo or rustc of mine: I ran none.
  SIX builders are live and every one parent-chains to Runner.Worker.exe <- Runner.Listener.exe <- RunnerService.exe: cargo 40448, cargo-nextest-driven cargo 15424, rustc 10296/34136/45892/44140. That is the post-merge CI you named. Attributed by authenticated ancestry, not by name.
  Free space 156.2 GiB at START -> 203.6 GiB at END, +47.4 GiB. I created nothing and deleted nothing; the reclaim happened during the window and I did not measure its agent, so I record the delta and attribute it to nobody.

W-1 remains ungranted and I start nothing. Standing by.