fix(B.6): turn-first auto-walk + tiny margin; close #67 doors; file #68 remote arrival

10 Hz heartbeat (301281d) made ACE see us in-radius before its
MoveToChain timeout; user confirmed doors work now. Closing #67 — root
cause was 1 Hz position outbound on our side, not anything door-
specific. Same fix unblocked door + NPC.

Two visible refinements:

1. Turn-first gate. User report: 'when I use from far range, I should
   face that object and then start moving. Now it starts running
   before facing is complete.'
   ApplyAutoWalkOverlay now suppresses Forward motion when the
   heading delta to the target is > 30°. Body turns IN PLACE first,
   then walks forward once roughly aligned. Within the 30° band the
   body walks while finishing the residual turn. Matches the user-
   observed retail rhythm.

2. Arrival margin shrunk 0.2 m → 0.05 m. User report: 'NPC dialogue
   fires, but still a bit too close. In retail it fires from a longer
   range.' With the 10 Hz heartbeat the server-side Player.Location
   tracks us within ~100 ms, so the bigger safety margin is no longer
   needed — only a tiny epsilon to absorb the sub-tick race between
   local arrival fire and the next outbound packet.

Filed #68: remote players' running animation doesn't transition to
Ready on auto-walk arrival when observed from acdream. Separate
visual bug — server-side action completes correctly; just the cycle
on the dead-reckoned remote body doesn't flip back to idle.

docs/ISSUES.md

@@ -46,35 +46,44 @@ Copy this block when adding a new issue:
 
 # Active issues
 
-## #67 — Door Use action doesn't complete after auto-walk arrival
+## #68 — Remote players don't stop running animation on auto-walk arrival
 
 **Status:** OPEN
-**Severity:** MEDIUM (M1-affecting — doors are M1 demo target 2)
+**Severity:** LOW-MEDIUM (visual only — server-side action completes correctly)
 **Filed:** 2026-05-15 (B.7 visual verification)
-**Component:** net / interaction
+**Component:** motion / remote dead-reckoning / animation cycle
 
-**Description:** After B.6's auto-walk + B.7's flush-AP-and-re-send, NPC
-dialogue fires correctly on out-of-range Use. But Use on a door from
-out-of-range still doesn't open the door — the player walks to the
-door, sends the re-send, and nothing happens.
+**Description:** Observing a retail player from acdream as they approach
+an NPC at a distance: the remote body's run animation keeps cycling
+even after the body has visibly stopped at the NPC. Retail-side the
+character stopped; the action (dialogue) fired; but our client's
+animation never transitioned RunForward → Ready.
 
-**Suspected causes (need investigation):**
-1. Door's `objDist` on the wire might be different from what we
-   parse, so the local arrival lands outside ACE's actual
-   door-use radius.
-2. ACE's `Door.ActOnUse` may require additional client-side state
-   (specific stance, motion, facing) that our re-sent Use lacks.
-3. The door's ObjectDescriptionFlags `BF_DOOR (0x1000)` may not
-   be properly captured / forwarded for our picker's per-type
-   radius logic to fire.
+**Suspected:** `RemoteMoveToDriver` detects arrival via
+`DriveResult.Arrived`, but the consumer site (per-tick loop in
+`GameWindow.TickAnimations` or wherever the remote body's cycle is
+driven) doesn't flip the animation cycle back to Ready on arrival.
+Alternatively the cycle persists because ACE doesn't broadcast a
+follow-up `UpdateMotion(Ready)` — relying on the client to detect
+arrival from the wire's distance threshold instead.
 
-**Acceptance:** F or R-key on a selected door from > 0.6 m runs the
-auto-walk, arrives, opens the door (player walks through; B.4c swing
-animation plays).
+**Files (likely):**
+- `src/AcDream.App/Rendering/GameWindow.cs` — wherever per-tick motion
+  for remote entities reads `RemoteMoveToDriver`'s state. Need to
+  call `SetCycle(NonCombat, Ready)` on arrival.
 
-**Files (likely):** `src/AcDream.App/Rendering/GameWindow.cs`
-`SendUse`; `src/AcDream.App/Input/PlayerMovementController.cs`
-arrival; `references/ACE/Source/ACE.Server/WorldObjects/Door.cs`.
+**Acceptance:** Retail player observed running up to an NPC visibly
+stops running animation at arrival distance, transitions to idle.
+
+---
+
+## #67 — [DONE 2026-05-15 · `301281d`] Door Use action doesn't complete after auto-walk arrival
+
+**Status:** DONE — fixed by `301281d` (10 Hz heartbeat during motion).
+With ACE seeing our position in near-real-time, its `CreateMoveToChain`
+converges normally for doors as well as NPCs. Root cause was 1 Hz
+position sync on our side, not anything door-specific. User confirmed
+doors work after the heartbeat bump.
 
 ---