#299 — the ONE authorized run is SPENT. Result is FAST, not a stall. I did NOT reproduce the condition.

SUBJECT/CONDITIONS
exe .worktrees/299-instr/target/release/spt.exe, sha256 5FBBDB39E52E398DDB752884C78017E39E824134802DC19E315550FE440235BA, built from detached d5fe86c3, release, jobs=2, 11m14s, rc=0.
Default home tag 78bf18a9fd96fdc6. Daemon re-anchored by direct Win32 query IMMEDIATELY before launch: pid 4732, spt.exe, created 2026-09-11T04:17:53.3401860Z, exe C:\Users\decid\AppData\Local\spt-core\bin\spt.exe, cmdline "daemon run --detached"; all six seed/broker pipes present. Identical to the 09:50Z anchor — same process, never refreshed.
SPT_PUMP_TRACE=1, unpiped `endpoint list --show-all` (stdout+stderr to FILES, not pipes). hertz sent START 10:08:29Z, END 10:08:51Z; he launched nothing in the window.
Wall 1756 ms, exit 0, stdout 3349 B, stderr 75241 B (500 trace lines).

MEASURED STAGE ATTRIBUTION (in-CLI endpoint_list = 1230 ms)
- 0 -> 457 ms  PRE-SUBNET. endpoint_list started at 0, first milestone (producer=loading_subnets) at 457. 37% of the run, and the current instrument attributes NONE of it. This block was not in the hypothesis.
- unlisted fan-out total 634 ms (barrier) / 632 (wrapper) / 631 (worker) = 51%.
- roster.read_model 127, roster.enumerate 111 (n=2), roster.snapshots 4, roster.subnets 2, render/visibility/nested/project_index/node_identity 0.
(Stages nest; I am not claiming the children sum to the parent.)

THE FAN-OUT, EXACTLY
Population on this node was ONE: unlisted.worklist rows=1 probes=1 not_asked=0 window_cap=16 outer_budget_ms=10000. One peer, endpoint "w2-helper-gateway" node 69d4fbd6…3107d. One window.
Its 631 ms is ENTIRELY presence.dial: ensure_broker 0, ipc_connect_hello 0, route 0, then dial -> 628 ms -> outcome=Err(Custom { kind: Other, error: "connect failed: Internal consistency error" }).
So it did NOT time out — it ERRORED, at 628 ms, well inside the 10 s ceiling.

TWO THINGS THIS ESTABLISHES THAT THE SOURCE READ DID NOT
1. The fan-out DOES run on `--show-all` and DOES block before print — previously falsifiable and unmeasured. Now measured.
2. BUDGET DISAGREEMENT, structural: the wrapper's per-probe wall wait is 10000 ms (PRESENCE_PROBE_CEILING), but presence.dial's own carrier budget is 30000 ms (budget=carrier_wall_reply_includes_broker_permit_quic_membership budget_ms=30000). The dial can outlive the outer ceiling. The instrument records this directly: outer_wait cutoff_is_completion=false, window producer_completion=not_implied, unlisted.worker budget=outer_cutoff_does_not_cancel. A probe abandoned at 10 s is still dialling for up to another 20 s.

WHAT I DID NOT ESTABLISH
- NOT that the fan-out causes perri's 10120/10105 ms. Those are consistent with THIS SAME single probe reaching the ceiling instead of erroring at 628 ms, but I observed the fast arm only. One sample, one arm.
- NOT what the 457 ms pre-subnet block is. It is now the largest unattributed cost in a fast run and I would want it attributed before proposing any remedy.
- Your correction about fast-failing peers needs one qualification from this data: this peer FAILED and still cost 628 ms. A failure is not free — the cost is in the dial, not in the ceiling.
- Registry access is chatty but cheap here: 34 sqlite opens and 68 lookup_address calls, 68 ms total, max 2 ms each. Each open carries a 5000 ms busy budget, so cheap-here is not cheap-under-contention — but I measured no contention.

REMEDY: I am proposing NONE yet, per your standing instruction. The smallest remedy is not derivable from one fast sample, and the honest next question is whether the slow arm is (a) this same dial reaching 10 s or (b) the unattributed 457 ms — those want different fixes. Tell me if you want a second run scoped to discriminate those two, and I will not take one until you say so.

Trace preserved at scratchpad/299-run-stderr.txt (500 lines) + 299-run-stdout.txt. Nothing committed. Pool for 299-instr still claimed for lane todlando-299-instr.

#49/#267: `cargo check -p spt-daemon --jobs 2` is RUNNING NOW in .worktrees/49-267-obs under its own claimed pool (preflight: no builders, 114.1 GB free, CPU 41%). traceable-reqs check follows. Your Q3 wording note is taken — I will re-read and correct it to report the first not-drained OBSERVATION without implying it was the first evaluation.

#300: both your messages read; the amended scope supersedes. Queued behind the above, not started.