PREDICTIONS — WINDOW 6 at cba18cd5 (69438c01 + the BOUND-PORT unit cell)
Filed by hertz BEFORE any execution of this sha. Compile-gate already measured:
cargo test -p spt-daemon --lib --no-run TRUE EXIT 0, 0 errors, 0 warnings.

────────────────────────────────────────────────────────────────────────────
Q1 — THE NEW CELL, by name:
  docshost::tests::the_bound_docs_port_publishes_only_for_a_broker_backed_listener_and_retires_on_drop
PREDICT GREEN, with all four of its asserts holding in order:
  (a) bound_docs_port() == None before any listener runs;
  (b) a brokerless start_serving at port 0 returns a real nonzero ephemeral port;
  (c) bound_docs_port() is STILL None after that successful bind — the publish gate;
  (d) after a manual store, Some(bound), and None again once BoundDocsPort drops.
If (c) is RED the publish gate is not what the module comment claims and it is a PRODUCT
finding, not mine. If (a) is RED the global was dirty before the cell ran, which under
nextest's process-per-test would mean something publishes at process init — also product.

Q2 — RED-FIRST, product-side mutation, reverted immediately, verified by oid before arm 2.
Two arms available; run the GATE arm first because it is the claim nothing else in the tree
covers. Budget permitting, both; if only one build is affordable, the gate arm alone.
  ARM R-GATE: hoist `BOUND_DOCS_PORT.store(bound, Ordering::Release)` OUT of the
  `broker.as_ref().map(...)` so every listener publishes.
    PREDICT RED at assert (c), left Some(<the ephemeral port start_serving returned>),
    right None. Asserts (a) and (b) still pass; (d) is never reached.
    A GREEN here refutes the CELL, not the product — it would mean (c) cannot fail and
    certifies nothing — and I would report it as that.
  ARM R-DROP: delete `BOUND_DOCS_PORT.store(0, Ordering::Release)` from `impl Drop for
  BoundDocsPort`.
    PREDICT RED at assert (d)'s final line, left Some(<same port>), right None, with
    (a), (b), (c) all passing first.
NOTE the mutations are OPPOSITE in direction: simply deleting the publish store leaves
(c) passing, because (c) expects None. The mutation that falsifies (c) has to make a
brokerless listener PUBLISH, not stop publishing. Stating it because "comment the store
out" reads as the other thing and would have produced a green arm read as a control.

Q3 — THE TWO PRE-EXISTING REDS, as an A/B on the rig's TMP. The mechanism is already
PROVEN without a run (see below), so this is confirmation plus a negative control, not an
open question.
  ARM A, default (rig FIXED, TMP base outside the tree):
    registryhost::tests::recent_projects_for_dedups_newest_first_excludes_spt_internal PASS
    projwriter::tests::batched_complexity_counters_hold                                 PASS
  ARM B, HERTZ_RIG_TMP_IN_REPO=1 (old in-repo placement, deliberately restored):
    registryhost... FAIL at registryhost.rs:1404, got ["github-com-bigscreenvr-spt-bs-core"]
    projwriter...   FAIL at projwriter.rs:842, got Some("spt-bs-core")
  If ARM A fails, the TMP placement is NOT the whole cause and the mechanism is incomplete.
  If ARM B passes, the mechanism is wrong outright and I withdraw it.
  WHAT IS ALREADY MEASURED, zero cost, with a control:
    git -C <old priv: EVID/temp/w5-lib-full> rev-parse --show-toplevel
      -> C:/Users/decid/Documents/projects/spt-core   (remote: the bs-core URL)
    git -C C:/Users/decid/AppData/Local/Temp rev-parse --show-toplevel
      -> fatal: not a git repository                  (todlando's and CI's placement)
  And the observed strings are REMOTE-derived, not folder-name-derived (todlando's
  derivation, re-checked): slug(remote) == the registryhost value, display_from_url(remote)
  == the projwriter value. The candidate folder names on this box — 304-product, hertz-304,
  spt-core — appear in neither, so the fallback path is excluded rather than merely
  disfavoured.

Q4 — THE FULL UNFILTERED LIB at cba18cd5 under the FIXED rig (ARM A conditions):
  PREDICT 988 tests run, 988 passed, 0 failed.
  Arithmetic, stated so a miss is diagnosable: my w5 run was 987 run / 985 passed / 2 failed;
  +1 for the new cell = 988 run; the 2 failures were the TMP artifact and the fix removes
  them = 0 failed. LIMIT: this assumes the cfg gap stays at the 8 todlando measured, and the
  absolute is platform-shaped — the sound arms are the +1 and the -2. I am predicting the
  WHOLE-SUITE number this time and not a single module's delta, which is exactly where my
  P2 went wrong last window.

Q5 — LEAKY: predict the same FOUR brainproc cells leak (clear_before_spawn_defeats_exact_
generation_stale_file, ready_but_old_gen_never_drains_does_not_promote_rolls_back,
stale_generation_minus_one_ready_never_promotes, trial_kills_alive_never_ready_candidate_
before_rollback), none failing. broker::windows_session_is_zombie... and
livehost::legacy_psyche_sweep_guard... leaked in todlando's run and NOT in mine, so for
those two I predict nothing and will report whichever way they land — a leak set that moves
between runs on identical bytes is run-shaped, and that is the finding rather than a defect
in any one cell.

Q6 — POOL: no SPT_POOL_FOREIGN, no lane-identity refusal (branch unchanged, still unlanded).
A lock wait may appear and is attributable: the editor's rust-analyzer builds into this
lane's pool on its own schedule (IR-100), and it showed up in the compile-gate log for this
very sha. I will name it rather than let an unexplained lock wait read as a foreign builder.