fix(streaming): make a demoted landblock render-ready like a published one (#280 D-1)

Both #280 review lenses returned FAIL on the same defect, and both were
right. IsRenderNeighborhoodResident's widened outer arm requires
IsRenderReady out to FarRadius, justified by "a Far-tier landblock
registers with an empty mesh set and is therefore render-ready." That held
only for a landblock that ARRIVED as Far. The second, equally first-class
way to be Far tier is a Near->Far DEMOTE:

  DemoteLandblock -> EnqueueNearLayerRetirement
    -> LandblockRetirementStage.MeshReferences
    -> GpuWorldState.ReleaseLandblockMeshReferences
    -> LandblockSpawnAdapter.OnLandblockUnloaded  => WantsLoaded = false

while DetachNearLayer deliberately keeps the landblock loaded, terrain-mesh
resident, terrain-collision resident and DRAWN. Nothing re-publishes an
already-loaded landblock, so the demoted member satisfied NEITHER arm of
the gate, permanently: wormhole tunnel plus centered "In Portal Space -
Please Wait..." forever, no recovery short of relog.

Reachable by ordinary play. Two consecutive recalls to the same landblock
with walking in between makes ChangesStreamingCenter false, so there is no
origin recenter and the region recentres through the ordinary demote diff.
Also reachable via a mid-hold quality-preset drop -- ironically the exact
scenario ReconcileDestinationReservationRadius was added to support. The
pre-#280 radius-1 gate never touched that band, because nothing inside the
Near ring can demote.

FIX SHAPE. Make the two routes genuinely equivalent rather than teaching
the predicate to tolerate the difference. ReleaseLandblockMeshReferences
becomes "reconcile the registration to the post-retirement tier": after the
release converges, if the landblock is still loaded AND still Far tier,
re-assert the empty registration -- the identical OnLandblockLoaded(lb,
empty) a PublicationKind.Far activation makes. It is empty by construction:
DetachNearLayer retains only live server projections, which the adapter's
atlas-tier filter skips. A full retirement is unaffected (DetachLandblock
clears both _loaded and _tierByLandblock), and a throwing release still
retries because the re-assert is only reached after the adapter converged.

The alternative -- "|| (IsFarTier && IsLoaded)" at the gate -- was
rejected: it fixes one caller while leaving IsRenderReady meaning two
different things, which is precisely how this defect arose. After this
change the predicate reads "drawable at its current tier" for every caller,
with no knowledge of how the landblock got there.

WHY THE TESTS MISSED IT, fixed here too:

- Proof obligation P2 was discharged against RESIDENCY (the FarRadius+2
  eviction threshold) rather than against IsRenderReady, the gate's actual
  atom. The contract now carries the correction and the restated
  obligation: no transition may REVOKE IsRenderReady from a landblock that
  stays inside FarRadius.
- WorldRevealDerivedWindowIntegrationTests advertised itself as end-to-end
  against the real GpuWorldState but constructed it with no spawn adapter,
  so its IsRenderReady degenerated to IsLoaded via the "?? true". The
  single most load-bearing predicate in the change was stubbed out by a
  null in the test named after it -- the same shape as C5b's D3 and #276's
  three settler tests. Every fixture in that file now owns a real
  LandblockSpawnAdapter.
- The P1 test's comment described its subject as "a Near-shaped completion
  the streaming window has since DEMOTED to Far". It is not; it is a fresh
  PublishAsFar, the case that does hold. Corrected, since a future reader
  would have taken it as demote coverage.

Four new regression tests, all driving the real GpuWorldState +
LandblockSpawnAdapter + LandblockPresentationPipeline through an actual
demote, and all sabotage-verified in both directions (fail with the
production change reverted, pass with it):

  NearToFarDemote_LeavesTheLandblockRenderReadyThroughTheRealPipeline
  NearToFarDemote_LeavesTheLandblockRenderReadyUnderBudgetedRetirement
  TieredWindow_StaysResidentAfterAnOuterRingDemote
  OutdoorReveal_SurvivesAnOuterRingDemoteDuringTheHold

The budgeted variant exists because production composes
LandblockRetirementCoordinator.CreateBudgeted, whose MeshReferences stage
is a separate call site from the legacy pipeline's.

SECONDARY, same commit:

- R-1: ACDREAM_PROBE_REVEAL_RADIUS=0 was parser-accepted and
  Runtime-rejected -- it yields far = 0 for an outdoor destination, which
  fails invalid-readiness-shape on every acknowledgement, hanging the very
  A/B route the probe exists to measure. Parser floor raised to 1, with a
  7-case table test.
- R-2: the composite-warmup TRIGGER had silently moved onto the far
  window's critical path. Pre-#280 the gate and the composite domain were
  the same radius-1 square; #280 widened the gate without widening the
  domain, so every composite upload serialised behind the last outer-ring
  landblock for no readiness benefit. Warmup now starts once the NEAR
  sub-window is published -- trigger scope == domain scope, as before. The
  reveal gate is untouched: Evaluate still requires the full window AND
  composite readiness.
- AP-150 filed: acdream's RetailWaitCueDelay = 5 s arming is NOT retail's
  trigger, and #280's commit message got this wrong on both clauses. Retail
  emits the notice unconditionally per tunnel rotation segment, in the else
  arm of the segment-expiry test at 0x004D6FCD; segment duration is
  RandDouble(0.6, 1.8) s, byte-decoded at 0x004D6FE6. The 5.0 constant at
  VA 0x007991B0 is CellManager::CheckPrefetchStatus's prefetch RETRY
  cadence and has nothing to do with the cue. acdream's own 0.6/1.8 segment
  constants already match retail exactly; only the arming is wrong.
  Adopting retail's unconditional emit is filed as #329 rather than folded
  in here -- it is a user-visible presentation change and wants the user's
  eyes.
- AP-151 filed: the gate is materially STRICTER than retail on the
  mesh-build/GPU-upload axis. Retail's LScape::PreFetchCells blocks on DAT
  RESIDENCY only -- no geometry construction, no upload; that work is lazy
  at draw. acdream requires a DAT read, terrain mesh build, render-thread
  upload, spatial commit, collision admission and spawn-adapter activation
  per member of a 625-member window, metered at MaxCompletionsPerFrame.
  Nothing bounds the hold. This is the OPPOSITE asymmetry from AP-149; both
  are live at once, on different axes.
- AD-2's amendment stated the false Far-tier readiness assumption verbatim;
  corrected, along with the same error in
  claude-memory/reference_two_tier_streaming.md, which now carries an
  explicit DO-NOT-RETRY on the special-case-the-predicate shape.
- AP-115 scope-noted (it covers the cue's presentation, not its arming).
- #326's SmartBox::set_mid_radius citation corrected: the entry is
  0x00453180; 0x004531D0 is the mid-function re-arm branch.

Blast radius: GpuWorldState, LandblockSpawnAdapter,
WorldRevealReadinessBarrier and StreamingDiagnostics are all App-internal;
AcDream.Headless and AcDream.Runtime reference none of them outside
comments. Headless tests run green as part of the gate below, per C5b's
lesson about surveys that skip the no-window host.

Gates: Release build 0 errors, 18 pre-existing xUnit analyzer warnings.
Complete suite "dotnet test AcDream.slnx -c Release -m:1" with
ACDREAM_PAK_PATH set: 11,192 passed / 4 skipped / 0 failed, from a clean
rebuild (a prior session's deleted probe file had been compiled into a
stale test DLL). Baseline at fafc0b65 was 11,179 / 4 / 0; the +13 delta
reconciles exactly to this commit's additions -- 3 readiness tests, 1
integration test, 7 parser table cases, 2 warmup-trigger tests. None of the
known flakes #302/#308/#321 surfaced, and none is conflated with the
finding above.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/research/2026-08-05-280-contract.md

@@ -236,7 +236,7 @@ Which callers block:
 | `SmartBox::PlayerPositionUpdated` @ `0x00453903` (`:92508`), teleport arm | `ChangePosition(pos, arg2 != 0)` | **yes on teleport** |
 | `SmartBox::PlayerPositionUpdated`, ordinary arm | `ChangePosition(pos, 0)` | no |
 | `SmartBox::UseTime` @ `0x00455462` (`:94180`) | `ChangePosition(pos, 0)` | no |
-| `SmartBox::set_mid_radius` @ `0x004531D0` (`:92053`) | `ChangePosition(pos, 1)` | **yes, if already blocking** |
+| `SmartBox::set_mid_radius` @ `0x00453180` (re-arm branch at `0x004531D0`, `:92053`) | `ChangePosition(pos, 1)` | **yes, if already blocking** |
 
 `CellManager::ChangePosition` @ `0x004559B0` (`:94601`) additionally
 promotes any call to blocking while the latch is set
@@ -778,14 +778,43 @@ It is graphical-host-only; headless has no `ObserveWait` caller anywhere
 `"In Portal Space - Please Wait..."` on recalls **more often**, and the
 tunnel will run longer before the world appears.
 
-**This is retail behaviour, not a divergence.** The retail string is
-byte-identical (§1.6) and retail emits it repeatedly for the whole duration
-of a blocked prefetch, whose retry is quantised to 5 s (§1.5). A retail
-client at `LandscapeDrawDistance = 8` recalling into a cold cache sits in
-the tunnel with the cue and a `CURRENT/TOTAL` cell counter until all 289
-landblocks are in. acdream showing the cue on a recall is convergence
-toward retail, not away from it. **No register row is required for the
-longer hold or the more frequent cue.**
+**Longer holds ARE retail-convergent — but the argument below was wrong on
+both of its clauses, and is corrected here (2026-08-06, #280
+retail-conformance review, finding F2).**
+
+The retail string is byte-identical (§1.6; VA `0x007BD6A8`, verified). Two
+things this section originally asserted are not true of the binary:
+
+1. *"retail emits it for the whole duration of a blocked prefetch"* — the
+   emit site is inside `gmSmartBoxUI::UseTime`'s `TAS_TUNNEL*` branch, in the
+   `else` arm of the rotation-segment-expiry test at `0x004D6FCD`, and fires
+   **unconditionally per tunnel rotation segment** whether or not
+   `blocking_for_cells` is set. The cue is a property of being in the tunnel,
+   not of being blocked. Byte-decoded at `0x004D6FE6`-`0x004D7049`:
+   `teleportRotationDuration = RandDouble(0.6, 1.8)` s
+   (`0x3ffccccc/0xcccccccd` = 1.8, `0x3fe33333/0x33333333` = 0.6),
+   `teleportRotationEndAngle = RandDouble(0, 360)` (`0x40768000`).
+2. *"whose retry is quantised to 5 s"* — the 5.0 constant at VA `0x007991B0`
+   belongs to `CellManager::CheckPrefetchStatus` @`0x00455BE0`, the prefetch
+   **retry cadence**. It has no connection to the UI notice. #280's commit
+   message repeated this mis-attribution; it is retracted.
+
+What survives, and is the real justification: retail genuinely **blocks**.
+`SmartBox::UseTime` @`0x00455410` runs only `CheckPrefetchStatus` while
+`blocking_for_cells` is latched — object maintenance, physics, the game
+clock, landscape and ambient are all skipped. A retail client at
+`LandscapeDrawDistance = 8` recalling into a cold cache sits in the tunnel
+until all 289 landblocks are in. A longer acdream hold is therefore
+convergent *in kind*.
+
+**Two register rows ARE required, and were filed 2026-08-06:**
+
+- **AP-150** — acdream's `RetailWaitCueDelay = 5 s` arming is not retail's
+  trigger (see the out-of-scope note immediately below, which was right; the
+  error was concluding no row was needed).
+- **AP-151** — acdream's per-member predicate is much heavier than retail's
+  (mesh build + GPU upload vs. DAT residency), so the hold is not merely
+  "retail's, honestly measured", and nothing bounds it.
 
 Two adjacent facts, both **out of scope**, both worth writing down so a
 later session does not mistake them for #280 regressions:
@@ -873,6 +902,20 @@ performance story. Report both; do not report only the post-fix number.
   the entire fix rests on it: if a Far landblock is not render-ready, D2's
   outer arm never satisfies and the reveal hangs.
 - **P2 — The outer ring converges within the Far window's own lifetime.**
+
+  > **CORRECTED 2026-08-06 (both #280 review lenses, FAIL).** As written below,
+  > P2 was discharged against **residency** — "cannot be evicted" — when the
+  > gate's actual atom is `IsRenderReady`. Those are different predicates, and
+  > the gap between them is exactly the shipped defect: a Near→Far **demote**
+  > leaves the landblock resident and drawn while revoking its spawn-adapter
+  > registration, so `IsRenderReady` went permanently false and the gate could
+  > never open. Discharging a proof obligation against a predicate the code does
+  > not use proves nothing. The restated obligation is: **no transition may
+  > revoke `IsRenderReady` from a landblock that stays inside `FarRadius`** —
+  > which now holds because `GpuWorldState.ReleaseLandblockMeshReferences`
+  > re-asserts the Far registration on demote. Every remaining sentence below
+  > (hysteresis, recenter, dungeon collapse) is correct as stated.
+
   The window unloads at `FarRadius + 2` Chebyshev
   (`src/AcDream.App/Streaming/StreamingRegion.cs:208-209`), so an outer-ring
   member cannot be evicted while it is inside `FarRadius`. Prove the gate