perf #418: widen the destination-lane budget only while the reveal hold is active

While a destination reservation hides the world behind the authored
tunnel, the streaming frame meter now runs a hold-widened profile
(StreamingWorkBudget.WidenForDestinationHold): the time ceiling rises
from the authored 2 ms to an absolute 8 ms default
(ACDREAM_STREAM_WORK_HOLD_DEST_MS is a measurement-only override), every
count/byte dimension scales by the same factor so elapsed time stays the
authoritative guard (the measured binder is Time at both ceilings), and
the reserve fraction is re-derived (0.75 -> 0.9375) so the
NON-destination lane's absolute per-frame caps are unchanged. The
widening keys off the existing BeginDestinationReservation/
EndDestinationReservation bracket only, is derived per-Tick from the
CURRENT budget (mid-hold quality swaps compose), and a frame with no
reservation uses the authored budget verbatim (test-pinned). Portal
holds ride the same bracket as login holds by construction - intended,
and pinned by a kind-parity test through the real coordinator plus a
live @telepoi portal hold (kind=portal gate-ready 3589 ms).

Why: issue #418's next-hypothesis (1). Measured result: the ~5 s
publication drip collapsed to ~2 s (loaded 625/625 at ~3.0 s, tunnel at
64-66 fps), the portal-hold gate-ready fell to ~3.6 s - and login
gate-ready/total stayed at 8.4-8.8 s / 12.6-12.7 s, exposing the real
remaining pacer: the login-cold render-thread upload/registration
barrier behind GpuWorldState.IsRenderReady, which ran concurrently under
the old drip. Full attribution appended to docs/ISSUES.md #418; no
divergence-register row (the streamed result and reveal gate are
byte-identical; only the scheduling rate during a hidden hold changed).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/ISSUES.md

@@ -135,6 +135,60 @@ choreography (TunnelContinue 2–5 s + two 1 s fades) is retail behavior
 and is NOT a tuning target. Predicted result: gate-ready ~2–3 s +
 authored exit ≈ 5–8 s total — retail-feel at 2.2x retail's window.
 
+**2026-08-17 (hold-widening round, this commit): hypothesis (1) LANDED —
+the drip collapsed exactly as predicted (5 s → 2 s) — and the login total
+did NOT move, which is itself the round's finding: a concurrent
+render-thread phase was hiding under the drip and is now the exposed long
+pole.** The frame meter now runs a hold-widened profile ONLY while a
+destination reservation is active
+(`StreamingWorkBudget.WidenForDestinationHold`, keyed off the existing
+`BeginDestinationReservation`/`EndDestinationReservation` bracket — no new
+flags — and derived per-Tick from the CURRENT budget so a mid-hold quality
+swap composes): destination-lane time ceiling 2 ms → 8 ms (absolute
+default; measurement-only env `ACDREAM_STREAM_WORK_HOLD_DEST_MS`), every
+count/byte dimension scaled by the same factor (the measured binder is
+TIME — `[stream-tick] yieldReasons=publication-*/Timex…` at both the 2 ms
+and the 8 ms ceiling; proportional scaling keeps time authoritative
+instead of letting a byte cap become the accidental binder), and the
+reserve fraction re-derived (0.75 → 0.9375) so the NON-destination lane's
+absolute caps are unchanged (floor-exact at defaults:
+floor(256×0.0625) = floor(64×0.25) = 16). No-hold frames use the authored
+budget verbatim (`NoReservation_UsesTheAuthoredBudgetUnchanged` pins it);
+portal holds ride the same bracket by construction
+(`HoldWidening_AppliesToLoginAndPortalRevealsAlikeAndRevertsAtEnd` pins
+kind parity through the real coordinator + controller) and were PROVEN
+live: a @telepoi-yaraq portal hold in the same session recorded
+`kind=portal` gate-ready **3589 ms** / totalMs **8681 ms** at 64–66 fps.
+**Measured (two login A/B runs + one login-then-portal run, this
+binary): loaded 625/625 at 3062/3064/3023 ms (was ~6–7 s), tunnel frames
+64–66 fps through the widened burst (the 28–29 fps first-second window is
+process/session start, present at baseline) — yet gate-ready
+8594/8752/8368 ms and totalMs 12634/12727/12726 (baseline 12689/12734):
+UNCHANGED.** Attribution: after the last publication (~3.0 s) the
+streaming meter is fully idle (`[stream-tick] ops=0 yields=0`) for
+~4.7 s until render-ready (7941/8099/7715 ms) — the pacer is the
+render-thread upload/registration barrier behind
+`GpuWorldState.IsRenderReady` (terrain upload crossing the render-thread
+barrier + spawn-adapter registration,
+`StreamingController.IsRenderNeighborhoodResident`), which ran
+CONCURRENTLY under the old drip — that is why the old breakdown showed it
+as only a ~0.4–1.2 s TAIL (the probe doc's serial-edge caveat) — and
+takes ~7.7–8.1 s from process start regardless of the drip. The
+warmed-process portal run replaces the SAME 625-block window to
+render-ready in ~3.0 s, so the login cost is dominated by cold-start
+work (first-touch DAT decode / texture and mesh cache fill / driver +
+JIT warmup), not by window size or queue capacity. Login acceptance
+(gate-ready < 3500 / total < 10000) NOT met; the widening stays — it
+removes the drip as a pacer everywhere, collapses the portal-hold
+gate-ready to ~3.6 s, and is what exposed the real limiter. No register
+row: the streamed result and the reveal gate are byte-identical; only the
+scheduling rate during a hidden hold changed (same precedent as the
+previous round). **Ladder: 27.4 → 12.7 → login 12.6–12.7 (unchanged, now
+attributed to the cold render-thread barrier); portal-hold gate-ready
+~3.6 s / total ~8.7 s. Next lever: instrument and cut the login-cold
+render-thread upload/registration phase (t≈1–8 s, concurrent) — budgets
+are exonerated three times over.**
+
 ## #417 — World ambience keeps playing (and re-firing) on the character-select screen after the in-world logoff
 
 **Status:** ✅ FIXED 2026-08-17 (logout-audio round; fix + tests in the same