fix(motion): retail-faithful remote tick — clear body.Velocity, drive via seqVel

Replaces the hybrid that double-counted forward translation:
predicted body.Velocity (set per-tick by apply_current_movement) +
the seqVel-derived offset both pushed the remote body forward at
~11.7 m/s × dt for run, summing to ~23.4 m/s × dt — the user's
"way too fast" + 1-Hz blip.

Per the named-retail decomp investigation 2026-05-03 (research agent
report dispatched against acclient_2013_pseudo_c.txt for
CSequence::update + UpdatePositionInternal + UpdateObjectInternal +
adjust_offset, line citations in the env-var path comments):

  CPhysicsObj::UpdateObjectInternal (0x005156b0)
  → UpdatePositionInternal (0x00512c30)
    → CPartArray::Update (writes anim root motion into the offset frame)
    → PositionManager::adjust_offset (REPLACES the offset with catch-up
      when the body is far from the queue head; otherwise leaves the
      anim root motion alone — Frame::operator=(arg2, &__return)
      semantics, NOT additive)
    → Frame::combine (out = m_position + offset)
    → UpdatePhysicsInternal (out += body.Velocity × dt + 0.5·accel·dt²)

For a remote in steady-state RunForward where the server hasn't pushed
an explicit velocity, m_velocityVector ≈ 0 and ALL per-tick translation
comes from the animation root motion (CSequence::update_internal +
Frame::combine of crossed pos_frames keyframes). Our port doesn't
extract per-keyframe pos_frames from the .anm assets; instead
AnimationSequencer.CurrentVelocity is the synthesized equivalent
(RunAnimSpeed × ForwardSpeed averaged), passed through
PositionManager.ComputeOffset.

Concrete changes in the env-var (ACDREAM_INTERP_MANAGER=1) path:

* Pass seqVel = ae.Sequencer.CurrentVelocity to ComputeOffset (was
  Vector3.Zero — that disabled the animation-root-motion source and
  left only the queue catch-up to drive translation, which lagged
  server pace).
* Clear rm.Body.Velocity to Vector3.Zero for grounded remotes each
  tick. Mirrors retail's m_velocityVector ≈ 0 for remotes; prevents
  UpdatePhysicsInternal from adding a second 11.7 m/s × dt on top of
  the seqVel-driven translation.
* Stop calling apply_current_movement per tick. Retail only calls it
  on motion-state changes (per cdb traces from the L.5 investigation),
  not per physics tick. body.Velocity-based translation is now the
  AIRBORNE-only path (gravity integration during jumps).

Also reverts an unacceptable "scaling hack" (per-tick body.Velocity
scaled by observed serverSpeed/predictedSpeed) the user explicitly
rejected as patching over an unsolved structural problem.

GetMaxSpeed reverted to RunAnimSpeed × rate (matches ACE
MotionInterp.cs:670-678; the earlier "return bare rate" change came
from a misread of an x87-decompiled get_max_speed where Binary Ninja
showed the return type as void).

AnimationSequencer.SetCycle now ALWAYS overwrites CurrentVelocity for
known locomotion cycles (Walk/WalkBackward/Run/SideStepRight/
SideStepLeft) instead of gating on `CurrentVelocity.LengthSquared() <
1e-9f`. The gate was correct for non-locomotion entities with
dat-baked HasVelocity, but for Humanoid where the dat is silent and
the only thing that could set CurrentVelocity before synthesis was a
transition link's HasVelocity flag, the gate would silently leave the
body advancing at the link's velocity instead of the cycle's intended
steady-state.

Adds wire-arrival diagnostics gated on ACDREAM_REMOTE_VEL_DIAG=1
(SETCYCLE, FWD_WIRE) used to trace the bug to ground truth.

User-confirmed improvements vs prior state:
- Steady-state run no longer "way too fast"
- Run-in-circles smoother (rectangle effect gone)
- Jump landing in correct location
- Turn-left visibly turns left

Outstanding (not addressed by this commit, deferred for next
investigation): walk↔run direct transitions don't visibly switch the
animation cycle until the next motion event fires. Both legacy and
new paths exhibit the same behavior, so the bug lives in the
SetCycle queue manipulation pipeline shared by both — not in the
per-tick translation path that this commit revises. Wire trace
confirms ACE delivers the WalkForward → RunForward transition
correctly and SetCycle does fire for it.

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

src/AcDream.Core/Physics/AnimationSequencer.cs

@@ -510,42 +510,52 @@ public sealed class AnimationSequencer
         // decompiled from _DAT_007c96e0/e4/e8. The velocity is body-local
         // (+Y = forward, +X = right); consumers rotate into world space via
         // the owning entity's orientation.
-        if (CurrentVelocity.LengthSquared() < 1e-9f)
+        // For known locomotion cycles, ALWAYS overwrite CurrentVelocity with
+        // the synthesized value — even if the transition link set
+        // CurrentVelocity from its own HasVelocity flag. The link's velocity
+        // is for the brief transition (e.g. small stride into run-pose); the
+        // cycle's intended steady-state velocity is what consumers (remote
+        // body translation in GameWindow.TickAnimations env-var path) need.
+        // Without this, walking-to-running transitions left CurrentVelocity
+        // at the link's slow pace, and the user reported "it just blips
+        // forward walking" until another motion command (turn, etc) forced
+        // a re-synth. The gate that previously read
+        // `if (CurrentVelocity.LengthSquared() < 1e-9f)` allowed dat-baked
+        // velocity to win over synthesis — which is correct for non-
+        // locomotion (e.g. flying creatures with HasVelocity) but wrong for
+        // Humanoid run/walk/strafe where the dat is silent and the link
+        // velocity is the only thing setting it.
         {
             float yvel = 0f;
             float xvel = 0f;
-            // Low byte of the ORIGINAL (non-adjusted) motion tells us which
-            // intent the caller signalled. adjust_motion may have remapped
-            // TurnLeft → TurnRight / SideStepLeft → SideStepRight /
-            // WalkBackward → WalkForward, encoding the sign into adjustedSpeed.
-            // The speed sign is preserved in adjustedSpeed so we multiply by
-            // it rather than re-deriving per-case.
             uint low = motion & 0xFFu;
+            bool isLocomotion = false;
             switch (low)
             {
                 case 0x05: // WalkForward
                     yvel = WalkAnimSpeed * adjustedSpeed;
+                    isLocomotion = true;
                     break;
                 case 0x06: // WalkBackward — adjust_motion remapped to WalkForward
-                           // with speedMod *= -0.65f, so adjustedSpeed already
-                           // carries the factor. But the motion arg we see
-                           // here is the original (pre-adjust) 0x06, so we
-                           // still use WalkAnimSpeed — the negative sign of
-                           // adjustedSpeed flips the direction correctly.
+                           // with speedMod *= -0.65f.
                     yvel = WalkAnimSpeed * adjustedSpeed;
+                    isLocomotion = true;
                     break;
                 case 0x07: // RunForward
                     yvel = RunAnimSpeed * adjustedSpeed;
+                    isLocomotion = true;
                     break;
                 case 0x0F: // SideStepRight
                     xvel = SidestepAnimSpeed * adjustedSpeed;
+                    isLocomotion = true;
                     break;
                 case 0x10: // SideStepLeft — remapped to SideStepRight with
                            // negated speed; same handling as backward walk.
                     xvel = SidestepAnimSpeed * adjustedSpeed;
+                    isLocomotion = true;
                     break;
             }
-            if (yvel != 0f || xvel != 0f)
+            if (isLocomotion)
                 CurrentVelocity = new Vector3(xvel, yvel, 0f);
         }