feat(D6.2b): send retail-faithful raw forward_speed=1.0 on the wire

The outbound MoveToState now sends the RAW forward_speed 1.0 (omitted by
default-difference packing) instead of the pre-computed runRate, matching what
retail's client sends.

Settled the open question with a live echo-test: acdream sends forward_speed=1.0,
ACE broadcasts back RunForward @ runRate (not 1.0), and a retail observer saw
+Acdream run at full pace. So ACE RECOMPUTES the broadcast run speed from the
character's run skill and auto-upgrades WalkForward+HoldKey.Run -> RunForward for
observers. The earlier PlayerMovementController comment citing ACE
MovementData.cs ("ACE relays the speed, so the wire must send run_rate") was
wrong; corrected.

Changes:
- PlayerMovementController section 6: forward wire command is WalkForward @ 1.0
  (+ HoldKey.Run when running); LocalAnimationCommand still carries RunForward for
  the local cycle. Backward already 1.0. The MotionStateChanged detection now
  keys the walk<->run toggle off HoldKey + LocalAnimationCommand (forward_speed is
  constant 1.0); the forward_speed comparison is retained but never fires.
- GameWindow: reverted the D6.2b echo-test one-liner; the wire RawMotionState
  takes forward_speed from result (now 1.0).

The wire and the D6.2a local velocity are now both raw-1.0. Threading them onto
one shared RawMotionState (removing section-6's duplicate build) is a
behavior-neutral cleanup follow-up.

Full suite green (3255). Docs: roadmap + pseudocode doc updated with the
echo-test finding.

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

docs/plans/2026-04-11-roadmap.md

@@ -627,8 +627,16 @@ change must keep both phase plans in sync.
   lateral, turn feel unchanged; no crash/rejection). Retired register
   TS-22 + UN-5; added TS-34 (IsCreature guard no-op). `WalkAnimSpeed` unified to
   the retail-exact 3.11999989f. Pseudocode:
-  `docs/research/2026-07-01-d6-motion-interp-pseudocode.md`. NEXT D6.2b: the
-  echo-gated wire `forward_speed=1.0` question.)
+  `docs/research/2026-07-01-d6-motion-interp-pseudocode.md`.)*
+  *(D6.2b, shipped 2026-07-01:* the wire now sends the retail-faithful RAW
+  `forward_speed=1.0` (omitted by default-difference packing) instead of runRate.
+  Echo-test settled the open question: ACE RECOMPUTES the broadcast run speed from
+  run skill and auto-upgrades WalkForward+HoldKey.Run → RunForward — sending 1.0
+  still broadcasts RunForward @ runRate, and a retail observer saw +Acdream run at
+  full pace. The stale `MovementData.cs`-citing "ACE relays" comment was
+  corrected. Wire + velocity are now both raw-1.0; threading them onto one shared
+  RawMotionState (removing section-6's duplicate build) is a no-op-behavior
+  cleanup follow-up.)
 - **L.1c — Combat animation wiring.** Combat mode tracking, draw/sheath
   style transitions, attack swings by stance/power/height, hit reactions,
   evades/blocks/parries, and death handoff.

docs/research/2026-07-01-d6-motion-interp-pseudocode.md

@@ -166,7 +166,13 @@ Integration seams:
    AND the local velocity/turn pipeline (`apply_raw_movement` →
    `get_state_velocity` + turn omega). The separate GameWindow wire-construction
    is retired; `MovementResult` carries the raw state, GameWindow packs it.
-2. **`forward_speed = 1.0` on run (decomp-forced).** The raw `forward_speed`
+2. **`forward_speed = 1.0` on run — CONFIRMED viable (echo-test 2026-07-01).**
+   The echo-test settled it: acdream sends `forward_speed=1.0`, ACE broadcasts
+   back `RunForward @ runRate` (not `1.0`), and a retail observer saw +Acdream run
+   at full pace — so **ACE recomputes the broadcast run speed from run skill**
+   (the `MovementData.cs`-citing "ACE relays" assumption was wrong). The wire now
+   sends the retail-faithful raw `1.0` (D6.2b). Original reasoning below stands:
+   The raw `forward_speed`
    must be `1.0` when running, because `apply_run_to_command` multiplies by
    run-rate — carrying `runRate` in the raw state would double-scale to
    `runRate²`. So the wire now sends `forward_speed=1.0` (omitted by