revert: AnimationSequencer locomotion-cycle full-reset and link-skip

Both changes were too aggressive:

1. Full queue reset on locomotion-locomotion transitions (c06b6c5)
   — turned out the user's tests went through Ready (no direct
   walk↔run transitions in the wire), so the fix never fired
   and didn't address the actual bug.

2. Unconditional skip of every transition link
   — killed ALL transition animations across the board (jump
   landing, run-to-stop, sit-down, lie-down, etc.) for every
   entity, not just the locomotion-locomotion case. User
   correctly identified this as a much bigger regression.

Sequencer is back to pre-c06b6c5 baseline: ClearCyclicTail-only
on motion change, transition link enqueued normally. The
walk↔run-direct-transition issue (and the broader
remote-only-doesn't-update issue) remains open and requires a
different approach.

Confirmed regression isolation: local +Acdream's transitions in
acdream client work (visible legs switch correctly), and acdream
chars observed from a parallel retail client also have working
transitions. The bug is specifically when acdream observes a
RETAIL-driven character — somewhere in the inbound
UpdateMotion → animCycle picker → SetCycle path, the visible
cycle update is being lost. Filed for separate investigation.

Adds an env-var-gated HASCYCLE diagnostic in OnLiveMotionUpdated
that confirmed cycle resolution succeeds (HasCycle=True for both
RunForward 0x44000007 and WalkForward 0x45000005 on style
0x8000003D), so the bug isn't in MotionTable cycle lookup.

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

src/AcDream.App/Rendering/GameWindow.cs

@@ -2936,6 +2936,14 @@ public sealed class GameWindow : IDisposable
                     // gets the wire's (or seeded) ForwardCommand verbatim
                     // so apply_current_movement produces correct velocity.
                     uint cycleToPlay = animCycle;
+                    if (System.Environment.GetEnvironmentVariable("ACDREAM_REMOTE_VEL_DIAG") == "1"
+                        && (animCycle & 0xFFu) is 0x05u or 0x07u)
+                    {
+                        bool hc = ae.Sequencer.HasCycle(fullStyle, cycleToPlay);
+                        System.Console.WriteLine(
+                            $"[HASCYCLE] guid={update.Guid:X8} style=0x{fullStyle:X8} "
+                            + $"requestedCycle=0x{cycleToPlay:X8} HasCycle={hc}");
+                    }
                     if (!ae.Sequencer.HasCycle(fullStyle, cycleToPlay))
                     {
                         uint requested = cycleToPlay;

src/AcDream.Core/Physics/AnimationSequencer.cs

@@ -434,29 +434,7 @@ public sealed class AnimationSequencer
         // cycle. Without this, the old RunForward → ??? link would
         // continue draining for ~100 ms before the new Falling cycle
         // starts, defeating the "skip the link" intent.
-        //
+        if (skipTransitionLink)
-        // 2026-05-03: ALSO do a full drain when transitioning between
-        // FORWARD-LOCOMOTION cycles (Walk↔Run, Walk↔WalkBackward, etc.)
-        // — i.e. when both old and new motion's low byte is in the
-        // {0x05 WalkForward, 0x06 WalkBackward, 0x07 RunForward} set.
-        // ClearCyclicTail alone leaves _currNode in the previous cycle's
-        // non-cyclic head (link frames from a Ready→walk transition),
-        // and the visible legs continue playing those head frames before
-        // reaching the new run cycle. The user-reported symptom: walk→run
-        // direct transition (release shift while W held) did not visibly
-        // switch the leg cycle — body advanced at walk pace until the
-        // next motion event (turn / stop) re-fired SetCycle and finally
-        // aligned the queue. Live cdb trace of retail acclient.exe
-        // 2026-05-03 (tools/cdb-scripts/walk_run_motion_trace.log) shows
-        // retail uses an additive add_to_queue with no truncate — the
-        // MotionTableManager's per-tick CheckForCompletedMotions handles
-        // the natural progression. We don't have that machinery, so we
-        // emulate via a hard reset on the locomotion-cycle transition.
-        uint oldLow = CurrentMotion & 0xFFu;
-        uint newLow = motion & 0xFFu;
-        bool oldIsForwardLoc = oldLow == 0x05u || oldLow == 0x06u || oldLow == 0x07u;
-        bool newIsForwardLoc = newLow == 0x05u || newLow == 0x06u || newLow == 0x07u;
-        if (skipTransitionLink || (oldIsForwardLoc && newIsForwardLoc))
         {
             _queue.Clear();
             _currNode = null;