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>

docs/ISSUES.md

@@ -220,7 +220,50 @@ AP-150 (the five-second wait-cue arming, which is what produced line 265),
 
 ## #338 — The player resolves with stepUp/stepDown 0.400 where Setup 0x02000001 authors 0.600 / 1.500
 
-**Status:** OPEN
+**Status:** CLOSED 2026-08-07 — **headline REFUTED by full-capture statistics;
+the residual is AD-68, an async-residency placeholder, not a wiring defect.**
+
+The three-site probe (`ACDREAM_PROBE_STEP_HEIGHTS=1`) answered everything in
+one run:
+
+```
+site=prepare  stepUp=0.600 stepDown=1.500  authored=(0.600,1.500) scale=1.000
+site=publish  stepUp=0.600 stepDown=1.500  localEntityId=1000002
+site=resolve  stepUp=0.400 stepDown=0.400  onGround=False   <- once, early
+site=resolve  stepUp=0.600 stepDown=1.500  onGround=True    <- the whole session
+```
+
+The probe is edge-triggered per site, so the single early 0.400 followed by
+0.600/1.500 with no further change means the steady state carried the authored
+values for the entire session — including the passing #32 cliff test.
+Re-reading the ORIGINAL `337-support.log` that motivated this filing, with
+statistics instead of an eyeball: the authored pair appears **111,248** times,
+the 0.400 pair **358** times. The filing was built on an early line of a
+255k-line capture; the mechanism it alleged (values never wired to the mover)
+does not exist.
+
+**What the 358 actually are — AD-68.** `GetSetupMoverShape` returns a
+placeholder (empty spheres -> legacy capsule, 0.4/0.4 steps) while an entity's
+flat Setup is not yet resident; the local player has the same seconds-long
+window between controller construction and publication-candidate adoption
+(`CommitRuntimeOwnedController`). Retail loads synchronously and has no such
+window. The early 0.400 in tonight's capture was most plausibly a REMOTE
+player in that window — remotes also carry the IsPlayer mover flag, which is
+why the probe now prints the mover id (`feedback_probe_identity_attribution`).
+
+**What the filing was still worth:** it caught three false doc-comment claims
+in `PlayerMovementController` (retail "~0.4 m" twice; a
+`PlayerModeController.ApplyStepHeights` writer that never existed — corrected
+to the real writer chain), pinned retail's actual fallback (0.04, not 0.4,
+`CTransition::step_up` @0x0050b655), and produced AD-68's register row for a
+previously unregistered adaptation.
+
+**No production behaviour changed at this closure — there is nothing to
+verify in a live gate.**
+
+**Original filing below, retained for the record.**
+
+**Status (original):** OPEN
 **Severity:** unknown until measured, plausibly medium. A 1.5 m step-down is
 what keeps a mover attached to a descending slope; 0.4 m is not, so this is a
 candidate contributor to descent/edge feel — but that link is NOT established