#119 ROOT CAUSE: interior-id X-byte collision + player-landblock cache hints = cross-entity batch serving

The decisive probe (3cf6bcc) caught it live in ONE session: a 43-part
staircase entity (src=0x020003F2, healthy MeshRefs tZ=[0.35..15.15])
drew with cache=hit:3 restZero=3 - THREE batches belonging to a 1-part
entity - then under a different hint the correct hit:119. Two
compounding bugs:

1. interiorIdBase = 0x40000000 | (landblockId & 0x00FFFF00) resolved to
   0x40YYFF00 for landblock keys 0xXXYYFFFF - the landblock X byte
   DISCARDED. Every landblock in a map Y-row shared one id space:
   Holtburg town A9B3's 9th interior stab == the AAB3 tower's spiral
   staircase, both 0x40B3FF09. Fixed to 0x40000000|(lbX<<16)|(lbY<<8)
   (the scenery 0x80XXYY## scheme).

2. The Tier-1 classification cache's #53 tuple key (EntityId,
   LandblockHint) was fed the PLAYER's landblock at bucket-draw time
   (RetailPViewRenderer.DrawEntityBucket fabricates its tuple with
   ctx.PlayerLandblockId), so colliding ids from different landblocks
   shared a key: whichever entity classified first under a hint won,
   and the loser wore its batches all session (static fast path never
   re-classifies). Also: bucket-hinted entries were never swept by
   InvalidateLandblock(owner) - stale entries survived owner unload.
   Fixed: ResolveCacheLandblockHint derives the hint from the entity's
   owning cell (ParentCellId landblock, canonical 0xXXYYFFFF), falling
   back to the tuple id for ownerless paths (outdoor stabs/scenery,
   where the tuple IS the owner).

Explains the session-shaped repro exactly: town-login + run to the
tower hydrates/classifies town interiors first -> the tower staircase
cache-hits the town twin's batches (stairs missing/partial + a wrong
object near the floor - the "water barrel"); login-inside classifies
the tower first -> usually clean. meshMissing=0 / entSeen==entDrawn
both ways (everything draws, wrong batches). Likely also feeds #113's
distance-dependent phantom staircase (the town twin wearing the
tower's staircase batches).

3 new cache tests pin the collision contract + hint derivation.
Suites: App green / Core 1430+2skip / UI 420 / Net 294.

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

src/AcDream.App/Rendering/Wb/EntityClassificationCache.cs

@@ -12,12 +12,19 @@ namespace AcDream.App.Rendering.Wb;
 /// <b>Key composition:</b> entries are keyed by the tuple
 /// <c>(EntityId, LandblockHint)</c>, NOT by <c>EntityId</c> alone. Issue #53
 /// uncovered that <c>entity.Id</c> is NOT globally unique across all
-/// static-entity hydration paths: scenery (<c>0x80LLBB00 + localIndex</c>)
-/// and interior cells (<c>0x40LLBB00 + localCounter</c>) overflow at >256
+/// static-entity hydration paths: scenery (<c>0x80XXYY00 + localIndex</c>)
+/// and interior cells (<c>0x40XXYY00 + localCounter</c>, X-byte fixed
+/// 2026-06-11 — it used to be discarded entirely, #119) overflow at >256
 /// items per landblock, wrapping into the <c>lbY</c> byte and producing
 /// cross-LB collisions in dense forest/urban LBs outside Holtburg. Keying
-/// by the tuple is correct-by-construction regardless of any hydration
-/// path's id strategy.
+/// by the tuple is correct-by-construction ONLY when the hint identifies the
+/// entity's OWNING landblock — callers must derive it via
+/// <c>WbDrawDispatcher.ResolveCacheLandblockHint</c> (the entity's
+/// ParentCellId landblock when present, canonicalized <c>0xXXYYFFFF</c>),
+/// never a call-site landblock. The #119 "broken stairs + water barrel" was
+/// exactly this: the bucket draw path hinted every entity with the PLAYER's
+/// landblock, so colliding ids from different landblocks shared a key and
+/// served each other's batches.
 /// </para>
 ///
 /// <para>