docs+gate: #468 filed — the Holtburg doorway pose seats the player in the interior cell at a floorless point and it falls through the world; route-g3b pose 15 moved to the outdoor standing point

The 'empty plane under fog' frame the S4-c1 capture-pose self-gates produced
at frame 15 is the terrain seen from below by a falling player, not a draw
change: the camera probe holds playerCell=0xA9B4013F at (134.07,17.36) while
z drops 96 -> -20 m after materialization. The S3-state run had seated the
same request outdoors in 0xA9B40029 and stood. Placement is not the campaign's
domain; the gate pose is moved so the G3 frame is deterministic and the
original pose is kept in the issue as the reproduction. #462 recurrence on
the pre-S4 control build noted.

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

docs/ISSUES.md

@@ -39,6 +39,16 @@ confirmed closed by the owner, 11 need a focused live gate, and 43 are safe to
 remain closed. See
 [`docs/research/2026-08-28-owner-closed-issue-validity-audit.md`](research/2026-08-28-owner-closed-issue-validity-audit.md).
 
+## #468 — Teleport to the Holtburg cottage doorway pose seats the player in the house-interior cell at a point outside its floor; the player falls through the world
+
+**Status:** OPEN — found 2026-09-04 by the lead while running the G3 self-gate's capture pose 15 (`tools/overhaul-selfgate/route-g3b.txt`, `/teleloc A9B4013F 133.603592 13.391837 96.330009 …`, the retail capture's EYE pose used as a player pose). Placement/collision, NOT Campaign OVERHAUL v2 (the frame it produces is a correct render of a player in free fall); tactical, own fix. START at `claude-memory/project_placement_cutover_closed.md` (#331) and `project_physics_collision_digest.md`.
+
+**Evidence (probe run `logs/selfgate-20260904-063313-hd-probe`, `ACDREAM_PROBE_FLAP=1 ACDREAM_PROBE_TELEPORT=1 ACDREAM_PROBE_PLACEMENT_FAIL=1`, Release `3e76f71d5`):** `live: teleport materialized - snapped to <134.06796, 17.36479, 96.33501> cell=0xA9B4013F` — the requested (133.60, 13.39) moved 4.0 m in +y and 0.46 m in +x by the placement resolve and was claimed by the INTERIOR cell 0xA9B4013F; `[flap-cam]` then holds `playerCell=0xA9B4013F player=(134.07,17.36,96.34)` with the camera sweep resolving the eye (1.66 m above, outside the house) to the OUTDOOR cell `viewerCell=root=0xA9B40029`; once simulation resumes the player falls with no floor under it — z 96.34 → 95.54 → 93.36 → 89.80 → … → −20 m and beyond, accelerating, still `playerCell=0xA9B4013F`. No `[place-fail]` line fired. The frame at the screenshot is the terrain seen from BELOW (a flat plane under blue fog with the hills along the top edge) — the same picture the landed S4-c1 runs `logs/selfgate-20260903-234030-s4c1-landed-g3b`, `…-235044-s4c1-landed-g3b2` and `logs/selfgate-20260904-062148-g3b-tip-a2` produced at this pose (all three seated at (134.07, 17.36) in 0x13F). The S3-state run `logs/selfgate-20260903-165634-g3b` seated the SAME request at `<133.60359, 17.391838, 96.33501> cell=0xA9B40029` (outdoors, on the cobbles in front of the door) and stood — so the placement resolve is not deterministic for this request, and the same +4.0 m y move happened in every run.
+
+**Reading:** the requested point lies in the cottage's doorway wall/threshold; the placement resolve walks it out (+4 m y in every run) and then either lands outdoors in 0x29 (stands) or 0.46 m east claiming the interior cell 0x13F at a point outside the interior volume (falls — no walkable floor in that cell's BSP under the point, and an indoor-classified object never consults the terrain). First checks: (1) which resolve moves the point 4 m (`AdjustSetPosition` validation? the server's own `/teleloc`? — compare the wire Position in `PlayerMovementController.CommitCanonicalTeleportFrame` with the snapped result); (2) why the containing pick returns 0x13F for a point the good run classified as 0x29 — `CellTransit.BuildCellSetAndPickContaining`'s keep-current tail (retail `find_cell_list` leaves the result null and the caller keeps `curr_cell`; at a teleport the 'current' cell is the REQUESTED cell) versus the outdoor XY-column candidate; (3) what differed between the S3-state run and the three later runs (hydration order at materialization? the previous position/heading?). A fall after a valid materialization is the #145/#138 family's opposite: the world was ready, the point was wrong. The pre-S4 A/B control could not run (#462 stalled the 6575cfcee build's login twice); no longer needed once the probe showed the fall.
+
+**Gate consequence:** route-g3b pose 15 is moved to the good run's standing point `/teleloc A9B40029 133.603592 17.391838 96.330009 0.977940 -0.143531 -0.022038 0.150157` (commit with this entry) so the G3 frame is deterministic; the original pose stays here as the reproduction.
+
 ## #467 — Running forward from the cathedral stairwell stops at the corridor mouth: the character runs in place
 
 **Status:** OPEN — found 2026-09-03 21:19 by the lead's #464 running reproduction (Release `590fbb66c`, local ACE, GM character with run skill 15230). Not a Campaign OVERHAUL v2 item (movement/collision, not world solidity); tactical, own fix.
@@ -152,6 +162,8 @@ a 0.1 ms median is flagged; the stationary sample already waits. Until then, jud
 
 ## #462 — Login reveal into an interior cell stays `ready=True materialized=False` for 180 s (foundry `0xA9B40176`)
 
+**Recurrence (lead, 2026-09-04):** the pre-S4 A/B control build (`6575cfcee`, worktree `s3-review-fix`) stalled at the login reveal in `0xA9B40176` (foundry) twice in a row — `logs/selfgate-20260904-042324-pre-s4-g3b` and `logs/selfgate-20260904-062354-pre-s4-g3b-2`: `event=readiness … ready=True` then never `materialized`, `event=cancel` at the graceful logout, process exit 0xE0434352 (#461 class). The S4-c1 tip logged in at the same cell fine minutes earlier; whether the stall is build- or timing-dependent is unknown.
+
 **Status:** OPEN — found 2026-09-03 by the Campaign OVERHAUL v2 G3 self-gate part C (`logs/selfgate-20260903-165745-g3c`, Release at `2fbfdf18a`).
 **Severity:** HIGH for automation, MEDIUM for play (a fresh login that never leaves portal space)
 **Component:** Runtime reveal generation (Login kind) — the readiness → materialization edge