docs: #161 landing-pose evidence trail from the live retest (seq still Falling at first post-landing UM; suspect the funnel's Falling dispatch writing interpreted fwd + HitGround re-apply)

docs/ISSUES.md

@@ -73,15 +73,31 @@ actually steps at (Player_Move.cs / Creature GetRunRate usage).
 
 ## #161 — Remote jump landing holds the falling pose (no landing anim)
 
-**Status:** OPEN (2026-07-03, R4-V5 live verify)
-**Symptom:** observing a retail player jump from acdream: the arc plays,
-but on touchdown the character stays in the falling pose instead of the
-landing/idle transition. Landing path: the remote resolver landing block
-(GameWindow `rm.Motion.HitGround()` + K-fix17 SetCycle) — instrument
-whether HitGround's re-apply dispatches, whether the landing SetCycle
-fires, and whether the InWorld link fix (350fb5e3) changed it (links were
-being stripped on every remote dispatch until then — retest FIRST, this
-may already be fixed by TS-40's landing-transition links surviving).
+**Status:** OPEN (2026-07-03; retested after TS-40/`41006e79` — still
+broken; user: stuck in falling until the char moves or the window loses
+focus).
+**Evidence (launch.log, session bklydthrr, guid 0x50000001):** `VU.land`
+fires; Falling completions (0x40000015) flow; but the FIRST post-landing
+UM still reports `seq now motion=0x40000015` — the landing block's reset
+(rm.Motion.HitGround() apply + K-fix17 SetCycle) did NOT move the cycle
+off Falling. Recovery happened only via SUBSEQUENT wire UMs (the mover
+pressed keys); a stand-still landing gets none → stuck forever. The
+focus-change unstick hints a frame-advance/big-dt interaction as well.
+**Prime suspect:** the funnel's airborne branch dispatches Falling via
+DoInterpretedMotion with ctor-default ModifyInterpretedState=true →
+InterpretedState.ForwardCommand becomes 0x40000015; HitGround's
+apply_current_movement (interpreted branch for remotes) then re-applies
+the interpreted state — i.e. re-dispatches FALLING — instead of the
+pre-fall wire command. Check retail: does apply_interpreted_movement's
+falling dispatch (raw ~305730, fresh local var_2c params) really write
+interpreted fwd (bit 0x4000 in the local's 0x1EE0F default) — and if so,
+what exits Falling on a retail REMOTE landing (HitGround raw @305949
+apply_current_movement(this, 1, ...) — the arg2=1 semantics)? Also
+verify K-fix17's SetCycle actually executes there (add a probe) and
+whether it lost a fight with the same-frame HitGround apply ordering.
+**Where:** GameWindow remote landing block (`VU.land` region);
+MotionInterpreter.ApplyInterpretedMovement falling branch;
+HitGround/apply_current_movement.
 
 ## #162 — Observer-side moveto cancelled by ACE's autonomous MTS reflections (the "glide" class)