tune(motion): #39 — tighten UmGraceSeconds 0.5 → 0.2

User observed the Shift-toggle cycle transition was "not as fast as
retail" after fixes #3-#5 landed the velocity-fallback path. Worst-case
added latency was the full 500 ms grace window before the first UP
could refine the cycle.

200 ms covers the actual UM/UP race — UMs arrive on direction-key
events, UPs at 5-10 Hz, so the first UP after a fresh UM lands
~100-200 ms behind it. Below that, fallback could prematurely
overwrite a UM's cycle decision; above that adds latency for no
correctness benefit. Direction flips (W↔S, A↔D, Forward↔Strafe)
update via UM directly so they're unaffected by this change.

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

src/AcDream.App/Rendering/GameWindow.cs

@@ -3348,11 +3348,14 @@ public sealed class GameWindow : IDisposable
     /// velocity refinement is suppressed for a player remote. UMs are
     /// authoritative; the velocity fallback only fills the gap when retail
     /// does not send a fresh MoveToState (Shift toggle while direction key
-    /// held). 0.5 s is a defensible default — UPs arrive at ~5–10 Hz, so
-    /// a Shift toggle's first UP after the toggle is typically ~100–200 ms
-    /// after the most recent UM, well past the grace.
+    /// held). 200 ms covers the worst-case UM/UP race — UMs arrive on
+    /// direction-key events and UPs at 5–10 Hz, so the first UP after a
+    /// fresh UM lands ~100–200 ms behind. Tightened from 500 ms (commit
+    /// 8fa04af original) per user observation that the Shift-toggle
+    /// transition was visibly slower than retail; with 0.2 s the worst-case
+    /// added latency is just the UP cadence below it.
     /// </summary>
-    private const double UmGraceSeconds = 0.5;
+    private const double UmGraceSeconds = 0.2;
 
     /// <summary>
     /// Speed (m/s) above which a player-remote currently in WalkForward