test(physics): TS-4 fixture-first attempt reproduces the 2026-04-30 wedge; shortcut stays

Campaign P Slice P2 step 2-3
(docs/research/2026-07-30-response-layer-edge-family-pseudocode.md §4, §6
Step 3). Per the research doc's own port order, TS-4's Path-6 steep-poly
shortcut may only be removed after a fixture reproduces the original
"stuck in falling animation on a steep roof" symptom cleanly with the
shortcut disabled. No surviving live-session fixture exists from the
2026-04-30 L.4 commit (b1af56e); this adds a dat-free multi-frame capture
(Ts4SteepRoofWedgeCaptureTests) using BSPStepUpFixtures.SlopedUnwalkable's
63.4 degree slope, replayed at 30 Hz with gravity integrated between
PhysicsEngine.ResolveWithTransition calls -- the same idiom as
Issue185OutdoorStairsSeamReplayTests.

Against today's baseline (shortcut active) the capture is green, as
expected (the shortcut's explicit AddOffsetToCheckPos keeps the body
moving every tick by construction).

Scratch-removed the shortcut (both BSPQuery.cs sphere0/sphere1 branches,
not committed -- reverted after capture) and re-ran the same test: the
body falls and lands cleanly on the steep polygon at tick 17 (InContact,
OnWalkable=false, via retail's own permissive CTransition::check_walkable
LandingZ gate, pc:273202), then freezes at that exact position for the
rest of the run -- the exact historical wedge shape, tripping the test's
own >0.5s-frozen threshold at tick 33.

Root-cause diagnosis via ACDREAM_DUMP_EDGE_SLIDE=1: the freeze is upstream
of EdgeSlideAfterStepDownFailed/CliffSlide entirely (none of that
dispatch's diagnostics fire). TransitionalInsert's Phase 2 object-collision
check returns Adjusted on every retry attempt because Path 6's retail-
faithful SetCollide returns ADJUSTED_TS without repositioning the sphere
(unlike the interim shortcut, which explicitly pushes the sphere off the
face) -- the same steep polygon re-triggers Path 6 on the immediate retry,
forever, and Phase 3 (the sp.Collide handling that contains DoCheckWalkable,
the Placement re-test, and the TS-1 CliffSlide chain) is gated on Phase 1
AND Phase 2 both returning OK, so it is structurally unreachable from this
state. TS-1's completeness is moot here -- the code path that would call
into it never runs.

Per the mission's explicit escape valve: STOP here, keep the shortcut, and
report -- do not improvise a third variant. Full diagnosis, the exact
capture, and the concrete next research question (does retail's own
transitional_insert loop check sphere_path.collide on every iteration
regardless of Phase 2's own return value, or only when Phase 2 returns OK?)
are recorded in the research doc's §7 item 6 and the doc's headline; the
campaign plan's P2 section gets a matching status note.

Physics test suite: 1841 passed, 1 skipped (D4, pre-existing/unrelated), 0
failed.

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

docs/plans/2026-07-29-physics-parity-campaign.md

@@ -84,6 +84,15 @@ character state continuously.
 
 ### P2 — Response-layer edge family — retires TS-1, TS-4, AP-7; closes #166, #116
 
+**Status (2026-07-30):** TS-1 and AP-7 retired; #166 reattributed in
+ISSUES.md (no new code — see the research doc §3). **TS-4 is deferred, not
+retired** — the fixture-first removal attempt this doc's §6 Step 3 requires
+reproduced the historical 2026-04-30 L.4 wedge (a dat-free capture,
+`Ts4SteepRoofWedgeCaptureTests`); the shortcut stays in `BSPQuery.cs`. Root
+cause and the concrete next research step are recorded in
+`docs/research/2026-07-30-response-layer-edge-family-pseudocode.md` §7 item
+6. #116 is untouched (oracle-first, own session).
+
 The collision *response* layer (what happens after a hit): ground
 friction, cliff edges, downhill landings, near-perpendicular wall
 slides. One oracle-driven pass; the physics digest's DO-NOT-RETRY table