fix(p2): cellar-lip wedge — check_other_cells must use the LIVE sphere position

Root cause of the "blocked at the last cellar step" wedge (the primary,
ramp-climb family — 20/29 captured records). The prior session's pinned
"find_walkable is never called during the step-down" was a probe artifact:
a fresh [fc-dispatch]/[step-sphere-down] trace proves Path-3 StepSphereDown
IS reached for both the carried cell and the iterated other-cell.

The real divergence is in Transition.CheckOtherCells. Retail's
check_other_cells (acclient_2013_pseudo_c.txt:272735 → (*cell+0x88)(this))
re-collides the OTHER cells against the LIVE sphere_path.global_sphere — the
position AFTER the primary insert_into_cell ran. The primary collide can MOVE
the sphere: a Path-5 full-hit dispatches step_sphere_up, and a successful
step-up climbs the foot onto the cottage floor yet still returns OK. acdream
instead reused a footCenter snapshot captured BEFORE the primary collide, so
once the lip-riser step-up climbed the foot onto the floor, check_other_cells
still queried 0171 at the pre-climb (sunk ~0.25 m below the floor) position →
the foot spuriously near-missed the very floor it had climbed onto →
neg_step_up → a doomed second step_up vs the floor normal (0,0,1) whose
step_up_slide unwound the climb → validate_transition reverted → 0% advance.

Fix: re-read footCenter = sp.GlobalSphere[0].Origin at the top of
RunCheckOtherCellsAndAdvance (one line). Pre-fix 0/29 wedge records advanced;
post-fix 20/29 climb onto Z≈94.

No regression: full Core suite 1321 pass / 4 fail (the documented baseline:
Apparatus_Grounded_50cmOffCenter, 2× DoorBugTrajectoryReplay LiveCompare_*,
BSPStepUpTests.D4) / 1 skip. The 2 door LiveCompare divergences are
byte-identical with/without the fix (the door's step_up FAILS → sphere
restored → position unchanged → footCenter == live).

Tests: CellarLipWedgeTests.Fix_StaleFootCenter_RampRecordClimbsCottageFloor +
Fix_StaleFootCenter_MajorityOfWedgeRecordsAdvance (new, GREEN).
DocumentsResidualWedge_LiveFloorCp_SlidingNormalKillsPlusY documents the
remaining 9/29 (0,-1,0)-sliding-normal +Y-kill family (slide territory,
deferred to the visual gate).

Apparatus retained (gated on ACDREAM_PROBE_INDOOR_BSP): [fc-dispatch] in
BSPQuery.FindCollisions + [step-sphere-down] in BSPQuery.StepSphereDown +
CellarLipWedgeTests.Diagnostic_TraceRecordByIndex — strip once the residual
is resolved.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/research/2026-06-04-p2-cellar-lip-flatfloor-cp-handoff.md

@@ -1,6 +1,54 @@
 # P2 cellar-lip wedge — CANONICAL handoff (flat-floor contact-plane coin-flip)
 
-## ▶ NEXT-SESSION KICKOFF (START HERE — supersedes everything below)
+## ✅ PRIMARY ROOT CAUSE FOUND + FIXED 2026-06-05 (START HERE — supersedes UPDATE 2 below)
+
+**The pinned "find_walkable is NEVER called during the step-down" (UPDATE 2) was a PROBE ARTIFACT.**
+A clean `[fc-dispatch]`/`[step-sphere-down]` trace (TEMP probes, gated on `ACDREAM_PROBE_INDOOR_BSP`,
+in `BSPQuery.FindCollisions` + `StepSphereDown`) proved `find_walkable` (Path 3 / `StepSphereDown`)
+**IS** reached for both 0175 (primary) and 0171 (other-cell) during the step-down — UPDATE 2 mis-read
+it (the `[fc-dispatch]` cell logs `path.CheckCellId` = the carried cell 0175 even while iterating
+0171's BSP, because `CheckCellId` is the carried cell, not the iterated one).
+
+**THE REAL ROOT CAUSE (ramp-climb family, 20/29 records):** `Transition.CheckOtherCells` collided the
+OTHER cells against a **stale `footCenter`** snapshotted at `FindEnvCollisions` entry (TransitionTypes.cs
+~L1959) — i.e. BEFORE the primary `insert_into_cell` ran. The primary collide can MOVE the sphere: a
+Path-5 full-hit dispatches `step_sphere_up`, and a successful step-up **climbs the foot onto the cottage
+floor yet still returns OK**. Retail's `check_other_cells` (`acclient_2013_pseudo_c.txt:272735` →
+`(*cell+0x88)(this)`) reads the **LIVE `sphere_path.global_sphere`** (post-insert). acdream used the
+pre-climb snapshot, which is sunk ~0.25 m below the floor → the foot spuriously **near-misses the very
+floor it just climbed onto** → `neg_step_up` → a doomed SECOND step_up against the floor normal (0,0,1)
+whose `step_up_slide` unwinds the climb (it slides relative to `GlobalCurrCenter` = the step start, low Z)
+→ `validate_transition` reverts the whole step → **0 % advance**.
+
+**FIX (shipped):** in `Transition.RunCheckOtherCellsAndAdvance` re-read `footCenter =
+sp.GlobalSphere[0].Origin` before iterating other cells. One line + comment. Pre-fix 0/29 records
+advanced; post-fix **20/29 climb onto the cottage floor (Z≈94)**. **Zero regression** — full Core suite
+1321 pass / 4 fail (the documented baseline 4: `Apparatus_Grounded_50cmOffCenter`,
+2× `DoorBugTrajectoryReplay LiveCompare_*`, `BSPStepUpTests.D4`) / 1 skip. The 2 door `LiveCompare`
+divergences are **byte-identical** with/without the fix (the door's step_up FAILS → sphere restored →
+position unchanged → `footCenter` == live). Tests: `CellarLipWedgeTests.Fix_StaleFootCenter_*` (2 new,
+GREEN).
+
+**REMAINING RESIDUAL (9/29, OUT OF SCOPE this pass):** the `(0,-1,0)` sliding-normal **+Y-kill**
+(`AdjustOffset` slide-crease projects the into-cottage +Y onto the floor×wall crease = world X and zeroes
+it → only −X survives → hits the slab −X wall → step_up fails on the flat floor → revert). 7/29 records;
+record #6 is the canonical one (`DocumentsResidualWedge_LiveFloorCp_SlidingNormalKillsPlusY`). This is
+**slide-recovery territory** the kickoff said NOT to re-investigate, and is **suspected to be a
+buggy-trajectory artifact** (the stale slide accumulated only because the player was already oscillating;
+once the ramp-climb advances cleanly the player should not enter the south-wall-slide-into-doorway state).
+**Let the VISUAL GATE decide** whether it needs a follow-up before touching the slide. (Record #21 moves
+−Y away from the cottage and is likely a legitimate non-advance.)
+
+**VISUAL GATE (next):** run the client, walk up the Holtburg cottage cellar stairs — expect the last-step
+wedge GONE (smooth ascent onto the floor). Also re-confirm the inn door BLOCKS and a generic step-up
+climbs (the fix only changes `check_other_cells`'s position reference). If the ascent still intermittently
+wedges, the `(0,-1,0)` +Y-kill is live → investigate `AdjustOffset` slide-crease / the sliding-normal seed
+(with the visual evidence then justifying touching the slide). Apparatus: `[fc-dispatch]`/`[step-sphere-down]`
+probes + `CellarLipWedgeTests.Diagnostic_TraceRecordByIndex` reproduce any record in <200 ms.
+
+---
+
+## ▶ NEXT-SESSION KICKOFF (historical — its "find_walkable never called" framing was disproven above)
 
 **State:** M1.5 / P2 cellar-lip "blocked at the last step" wedge. A FAITHFUL deterministic reproduction now
 exists. The cause has been peeled through SIX evidence-disproven framings to one bounded question. No fix