fix(render): near plane 1.0m -> 0.1m (retail Render::znear) - corner see-through-wall; file #107-#109

The collided camera eye sits 0.3m from walls (viewer_sphere radius); a 1.0m near plane clipped the wall face away, so pressing the camera into a corner showed the clear color through the wall (gate result: unchanged by the flood fix - it was never a flood bug). Retail sets Render::znear = 0.1 flat in SetFOVRad (decomp :342173, initializer :1101867). All four cameras aligned. Also files #107 (indoor spawn wedge, 3-for-3), #108 (cellar-up terrain sweep across door opening), #109 (exit-door texture/background oscillation) from the 2026-06-10 visual gate; gate confirms the dac8f6a flood fix: room-room + indoor-outdoor transitions clean.

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

docs/ISSUES.md

@@ -3714,6 +3714,60 @@ Unverified. The likely culprits, ranked by suspected probability:
 
 ---
 
+## #107 — Indoor spawn wedge: player stuck (in air / in wall) when logging in inside a building
+
+**Status:** OPEN
+**Severity:** HIGH
+**Component:** physics / player-mode entry (`PlayerModeAutoEntry`, spawn teleport handling)
+
+Reproduces 3-for-3 (2026-06-10) when `+Acdream` logs in INSIDE the Holtburg inn (character
+logged out indoors): player-mode auto-entry fires (`auto-entered player mode` in the log),
+then the player hangs in the air / in a wall and movement input is ignored. One stuck run
+showed `live: teleport started (seq=1)` with no completion — ACE pushing a position
+correction that never resolves. The #106 gate-2 `isSpawnGroundReady` hold checks
+`SampleTerrainZ != null` (outdoor TERRAIN under the spawn) — an INDOOR spawn's ground is
+the cell floor, not terrain, so the relationship between the hold, the spawn teleport, and
+indoor grounding needs investigation. Outdoor spawns enter fine. Workaround: none from the
+client; relaunching re-wedges because the character is parked indoors.
+Apparatus when picking this up: `ACDREAM_CAPTURE_RESOLVE` + `ACDREAM_PROBE_RESOLVE` on a
+login-indoors run; logs `flood-fix-gate2.log` / `flood-fix-gate3.log` (untracked) hold the
+stuck-run output.
+
+---
+
+## #108 — Cellar↔main-floor transition: terrain (grass) sweeps across the upstairs door opening
+
+**Status:** OPEN
+**Severity:** MEDIUM
+**Component:** render / indoor PView (OutsideView slice vs interior-root depth handling)
+
+During the cellar→main-floor ascent (Holtburg), the door opening visible on the main floor
+shows the outdoor GRASS texture sweeping over it — "like outdoor ground rising up from the
+floor to cover it (as if watching it from below) and lowering back down when crossing up"
+(user gate, 2026-06-10, post-`dac8f6a`). Likely the landscape drawn through the OutsideView
+slice while the viewer is in the stairwell, with the eye below outdoor terrain height — the
+terrain surface crosses the doorway region as the eye rises. Needs its own capture (probe
+run on the cellar stairs) to pin whether the OutsideView region, the doorway depth-clear,
+or terrain-vs-cell draw order is at fault.
+
+---
+
+## #109 — Exit door across the room oscillates between door texture and background color
+
+**Status:** OPEN
+**Severity:** MEDIUM
+**Component:** render / indoor PView (exit-portal region vs door entity draw order)
+
+In a Holtburg house with a second exterior door: standing inside and looking at the OTHER
+exit door across the room, the door surface oscillates between its real texture and the
+background color, "almost like a mix of both" (user gate, 2026-06-10, post-`dac8f6a`).
+Suspect family: the per-frame interaction between the exit-portal OutsideView slice for
+that doorway, the doorway depth-clear (`ClearDepthSlice`), and the door ENTITY's draw —
+alternating which wins per frame. Distinct from the (fixed) flood strobe: the flood is
+stable now; this is a draw-order/depth oscillation localized to the door surface.
+
+---
+
 ---
 
 # Recently closed