refactor(runtime): extract local teleport and player mode

Move local teleport, player-mode, animation, shadow, and sealed-dungeon lifetimes out of GameWindow. Make player-mode entry transactional and isolate approach completions by controller lifetime and approach generation so stale callbacks cannot affect replacements.

Co-authored-by: Codex <noreply@openai.com>

docs/plans/2026-07-21-gamewindow-slice-6-update-frame-orchestration.md

@@ -425,6 +425,20 @@ one named legacy owner only; D/F must remove the exception before final cutover.
   inbound delete/recreate generation safety;
 - preserve the completed portal visuals and world-reveal barrier unchanged.
 
+**Completed 2026-07-22.** `LocalPlayerTeleportController` now owns the full
+local transit lifetime and its immutable network handoff, while
+`PlayerModeController` is the sole writer of controller, physics-host,
+player-mode, and chase-camera slots. Local animation, shadow synchronization,
+sealed-dungeon classification, viewport aspect, and approach-completion
+handoff are focused collaborators rather than window callbacks. Portal entry
+retires the one-shot auto-entry guard, host publication is transactional, and
+teleport work revalidates the live generation after every reentrant edge.
+Focused App/Core tests cover destination readiness, forced holds, same-cell
+placement, LoginComplete order, reset/disposal, GUID reuse, reentrancy,
+host rollback, auto-entry idempotence, and completion-mailbox ordering. The
+full App suite is green at 2,814 passed / 3 skipped. `GameWindow.cs` is 7,351
+lines at this checkpoint, down from the slice baseline of 15,723.
+
 ### F/G — camera, cutover, and deletion
 
 - extract player-mode enter/exit/toggle and current-owner state before camera