Decompose TUI app state and turn orchestration

Summary

The TUI app layer is still carrying too much responsibility across src/tui/app.rs and related src/tui/app/* modules. State shape, turn execution, orchestration, remote/session flows, and UI coordination are still tightly coupled.

Why this matters

• large blast radius for everyday TUI changes
• difficult to test turn behavior independently from UI state
• app state continues to grow as a god object
• remote/auth/turn flows are expensive to reason about

Proposed direction

Decompose the app layer into clearer boundaries such as:

• app state/data structs
• turn engine / assistant interaction orchestration
• remote session lifecycle
• auth/login flows
• UI-only state and presentation adapters

Suggested acceptance criteria

• src/tui/app.rs shrinks materially
• run_turn / run_turn_interactive orchestration is moved behind smaller units
• at least src/tui/app/remote.rs and src/tui/app/auth.rs are split into smaller focused modules
• new boundaries are covered by focused tests where practical
• validation remains green under fmt/check/clippy

Notes

This is a follow-up architecture issue after the repo-wide quality enforcement work landed.

Start by reading src/tui/app.rs and the related src/tui/app/* modules, especially src/tui/app/remote.rs and src/tui/app/auth.rs, to map state, turn execution, remote sessions, authentication, and UI coordination. Trace run_turn and run_turn_interactive, then inspect existing tests before proposing boundaries. Done means the app layer is materially smaller, focused modules have practical tests, and fmt, check, and clippy remain green.