docs: close #338 — headline refuted by full-capture statistics; AD-68 files the real residual

The three-site probe answered it in one run: prepare and publish carry
the authored 0.600/1.500 to the publication candidate, and resolve
receives exactly those values for the entire session after one early
0.400 reading. Re-reading the ORIGINAL 337-support.log with statistics
instead of an eyeball: authored pair 111,248 lines, 0.400 pair 358. The
filing was built on an early line of a 255k-line capture; the alleged
mechanism (values never wired to the mover) does not exist.

The 358 are AD-68, now registered: GetSetupMoverShape's placeholder
(empty spheres -> legacy capsule, 0.4/0.4 steps) during an entity's
async Setup-residency window, plus the local player's own seconds-long
window between controller construction and publication-candidate
adoption. Retail loads synchronously and has no such window. Left as-is
deliberately: shrinking it is streaming work.

The filing still paid for itself: three false doc-comment claims
corrected in PlayerMovementController (retail '~0.4 m' twice, and an
ApplyStepHeights writer that never existed anywhere in the tree —
replaced with the real writer chain), retail's actual fallback pinned at
0.04 (CTransition::step_up @0x0050b655), and the resolve probe now
prints the mover id, because the early 0.400 was most plausibly a
REMOTE player — remotes also carry IsPlayer — and the guid rule
(feedback_probe_identity_attribution) exists precisely to stop that
misread.

No production behaviour changed; nothing for the morning gate. AD
section 50 -> 51. Suite 11,234 / 4 / 0.

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

src/AcDream.Core/Physics/PhysicsEngine.cs

@@ -1935,6 +1935,14 @@ public sealed class PhysicsEngine
             // its two resolve calls. A silent probe proves nothing, so this
             // one sits where every caller must pass through. Filtered to the
             // player so remotes cannot drown it.
+            // #338 self-report, once per process, UNCONDITIONAL. The probe has
+            // now been silent through two placements, and "no output" cannot
+            // distinguish "this site is never reached" from "the flag is
+            // false". This line answers both directly instead of a third round
+            // of inference. One Interlocked per process; strip with the probe.
+            PhysicsDiagnostics.AnnounceStepHeightProbeOnce(
+                (moverFlags & ObjectInfoState.IsPlayer) != 0);
+
             // The flag test MUST precede the interpolated string: this site runs
             // per resolve, and building the detail eagerly cost 128 B/resolve
             // with the probe OFF — caught by Slice I1's zero-allocation gate,
@@ -1942,9 +1950,14 @@ public sealed class PhysicsEngine
             if (PhysicsDiagnostics.ProbeStepHeightsEnabled
                 && (moverFlags & ObjectInfoState.IsPlayer) != 0)
             {
+                // The mover id is REQUIRED here (feedback_probe_identity_attribution):
+                // remote players also carry IsPlayer, and the one early
+                // 0.400 reading this probe caught was nearly misattributed to
+                // the local player for exactly that reason — it was a remote
+                // in its Setup-residency window (AD-68).
                 PhysicsDiagnostics.LogStepHeights(
                     "resolve", stepUpHeight, stepDownHeight,
-                    $"onGround={isOnGround} hasBody={body is not null}");
+                    $"mover=0x{movingEntityId:X8} onGround={isOnGround} hasBody={body is not null}");
             }
 
             transition.ObjectInfo.StepDown = true;

src/AcDream.Runtime/Gameplay/PlayerMovementController.cs

@@ -168,13 +168,24 @@ public sealed class PlayerMovementController
 
     /// <summary>
     /// Maximum Z increase per movement step before the move is rejected.
-    /// Retail's <c>step_up_height</c> for human characters is ~0.4 m (hip-
-    /// level). Setting this too high lets the player teleport up small
-    /// buildings via the step-up scan finding any walkable polygon within
-    /// reach (Bug 3 in L.2.3 testing — walking into a steep slope mounted
-    /// the building's flat top instead of sliding off the slope).
-    /// Authoritative source is the player's <c>Setup.StepUpHeight</c> set
-    /// in GameWindow.cs at world-entry time.
+    ///
+    /// <para>
+    /// #338 (2026-08-07) — this comment previously claimed retail's
+    /// <c>step_up_height</c> for humans "is ~0.4 m" and that the value is
+    /// "set in GameWindow.cs at world-entry time". Both were false, and a
+    /// third false claim on the SphereList doc named a
+    /// <c>PlayerModeController.ApplyStepHeights</c> that has never existed
+    /// in the tree. The measured truth: the human Setup 0x02000001 authors
+    /// <b>0.600</b> up / <b>1.500</b> down; retail's fallback when NOT on
+    /// walkable ground is <b>0.04</b> (<c>CTransition::step_up</c>
+    /// @0x0050b655), and 0.4 appears nowhere in retail. The authoritative
+    /// writer is <c>RuntimeSetPositionMoverPreparation</c> (Setup-derived,
+    /// x scale) via <c>RuntimeLocalPlayerPhysicsPublicationState</c>'s
+    /// candidate, adopted by <c>CommitRuntimeOwnedController</c>. The 0.4f
+    /// construction default below survives only until that adoption — a
+    /// seconds-long window shared with AD-68's remote residency placeholder.
+    /// Live capture: 111,248 authored-pair resolves vs 358 placeholder ones.
+    /// </para>
     /// </summary>
     public float StepUpHeight
     {
@@ -188,11 +199,12 @@ public sealed class PlayerMovementController
 
     /// <summary>
     /// L.2.3a (2026-04-29): how far below the foot the step-down probe
-    /// reaches when transitioning between surfaces. Retail's
-    /// <c>step_down_height</c> for human characters is ~0.4 m. With the
-    /// previous 4 cm hardcoded value, walking off the top of a stair onto
-    /// the ground 25 cm below produced a one-frame contact-plane gap — the
-    /// animation system briefly flickered to falling.
+    /// reaches when transitioning between surfaces. (The original "retail's
+    /// step_down_height is ~0.4 m" claim here was wrong — the human Setup
+    /// authors <b>1.500</b>; see <see cref="StepUpHeight"/>'s #338 note. The
+    /// historical observation stands: with the very first 4 cm hardcoded
+    /// value, walking off a stair onto ground 25 cm below produced a
+    /// one-frame contact-plane gap and a falling-animation flicker.)
     /// </summary>
     public float StepDownHeight
     {
@@ -231,9 +243,11 @@ public sealed class PlayerMovementController
     /// TS-46 (2026-07-30): the player's own Setup ≤2-sphere list (dat
     /// <c>CSphere</c> Origin+Radius), verbatim per retail
     /// <c>CPhysicsObj::transition</c> (0x00512dc0) →
-    /// <c>SPHEREPATH::init_sphere</c> (0x0050c670). Set at world-entry by
-    /// <c>PlayerModeController.ApplyStepHeights</c> alongside
-    /// <see cref="StepUpHeight"/>/<see cref="StepDownHeight"/>. Default
+    /// <c>SPHEREPATH::init_sphere</c> (0x0050c670). Set alongside
+    /// <see cref="StepUpHeight"/>/<see cref="StepDownHeight"/> by
+    /// <c>RuntimeLocalPlayerPhysicsPublicationState</c>'s publication
+    /// candidate (#338: the previously-named
+    /// <c>PlayerModeController.ApplyStepHeights</c> never existed). Default
     /// (empty) falls back to <c>ResolveWithTransition</c>'s legacy
     /// (0.48, 1.835) two-scalar capsule reconstruction — the human Setup
     /// 0x02000001's authored spheres are (0,0,0.475) r=.48 and