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/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