docs(motion): #39 — candidate fix ineffective; refute Shift-toggle wire hypothesis

Visual-verify of commit 8fa04af in launch-39-candidate.log refutes the
static-analysis hypothesis that retail does not broadcast UMs on
HoldKey-only changes. The log shows:

- [FWD_WIRE] for retail actor 0x50000001 contains many direct Walk↔Run
  transitions (0x44000007 ↔ 0x45000005). ACE IS sending UMs on Shift
  toggle.
- [SETCYCLE] fires correctly per UM; Sequencer.CurrentMotion cycles
  through Walk / Run / Turn / Sidestep correctly per [UM_RAW].
- [UPCYCLE_PLAYER] never fired — UM grace correctly suppressed it
  (UMs at >2 Hz, well within 500 ms grace).
- User reports legs visually stuck in walking animation despite the
  wire/sequencer saying Run.

Conclusion: bug is downstream of Sequencer.CurrentMotion — same as
2026-05-03 hypothesis F. Most likely _currNode lands on the walk-to-run
transition link after SetCycle (`currNodeIsCyclic=False` confirmed in
[SCFULL]) and Advance does not progress past it to the cycle.

The candidate fix code (LastUMTime, ApplyPlayerLocomotionRefinement,
hysteresis constants, un-gated call site) is left in place — harmless
because UM grace blocks the velocity-fallback path while UMs arrive,
and the infrastructure may be useful for cases #2–#7 if those need
velocity fallback. But it does not close case #1.

Updates ISSUES.md #39 with refuted hypothesis + new evidence + next
step pointer. findings-static.md gains "Visual-verify result" §
documenting the diagnostic dump and recommending the next investigation
target be AnimationSequencer.Advance queue-handling.

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

docs/ISSUES.md

@@ -130,22 +130,41 @@ the same direction. Add a `LastUMUpdateTime` grace window (e.g.
 - No spurious cycle thrashing during turning while running (ObservedOmega
   doesn't trigger velocity-bucket changes).
 
-**Progress 2026-05-06 (candidate fix shipped, awaiting visual verify):**
+**Progress 2026-05-06 — candidate fix INEFFECTIVE per visual verify:**
 
-- `RemoteMotion.LastUMTime` added, stamped in `OnLiveMotionUpdated`.
-- `ApplyServerControlledVelocityCycle` un-gated for player remotes;
-  player path routed through new `ApplyPlayerLocomotionRefinement`:
-  - 500 ms UM grace window
-  - Forward-direction-only refinement (low byte 0x05 / 0x07)
-  - Hysteresis: Run → Walk demote < 4.5 m/s; Walk → Run promote > 5.5 m/s
-  - Skip SetCycle when neither motion ID nor speedMod changed meaningfully
-- Outer call site at `OnLivePositionUpdated` un-gated (`!IsPlayerGuid`
-  removed); function-internal route handles player vs NPC.
-- Diagnostic `[UPCYCLE_PLAYER]` line gated on `ACDREAM_REMOTE_VEL_DIAG=1`.
+Candidate fix `8fa04af` shipped a velocity-fallback path
+(`LastUMTime` + `ApplyPlayerLocomotionRefinement`), built on the
+hypothesis that retail does not send a fresh MoveToState on
+HoldKey-only changes. **That hypothesis is refuted.** Visual-verify
+log (`launch-39-candidate.log`) shows:
 
-Scope of this fix is **case #1 (Run↔Walk forward) only**. Cases #2–#7
-(backward, sidestep, direction-flips) remain deferred until TTD trace
-grounds retail's exact algorithm — see findings-static.md §"Does NOT".
+- `[FWD_WIRE]` for retail-driven actor `0x50000001` contains many
+  direct Walk↔Run UM transitions (`0x44000007 ↔ 0x45000005`). ACE
+  IS broadcasting UMs on Shift toggle.
+- `[SETCYCLE]` fires correctly for each transition; `Sequencer.CurrentMotion`
+  cycles through Walk/Run/Turn/Sidestep at varied sample moments.
+- `[UPCYCLE_PLAYER]` never fires (UM grace correctly suppresses it
+  while UMs arrive at >2 Hz).
+- User report: "blips forward in walking animation" — the visible
+  cycle stays in Walk despite the wire / sequencer saying Run.
+
+So the bug is **downstream of `Sequencer.CurrentMotion`** — same as
+2026-05-03 hypothesis F. Most likely `_currNode` lands on the
+walk-to-run transition link after `SetCycle`, the link plays as a
+walking-like pose, and `Advance` never advances past it to the
+run cycle. `[SCFULL]` confirms `currNodeIsCyclic=False` after every
+Walk↔Run transition.
+
+The candidate fix code is left in place — the infrastructure is
+harmless (UM grace blocks all calls in normal flow) and may be
+useful for cases #2–#7 follow-up if those turn out to need
+velocity fallback. But it does NOT close case #1.
+
+**Next investigation step:** target `AnimationSequencer.Advance`
+queue-handling for cyclic→cyclic direct transitions. See
+[findings-static.md](research/2026-05-06-locomotion-cycle-transitions/findings-static.md)
+§"Where the bug actually lives" + §"What to do next" for the
+specific code paths and recommended diagnostic additions.
 
 ## #42 — [DONE 2026-05-05 · ec59a08] Airborne XY drift on observed player remote jumps (~1 m horizontal offset over arc)