Roadmap clarification: will standalone TUI move to app-server-backed runtime for multi-client live sync?

Request

Could the team clarify the roadmap for TUI architecture:

• Is the standalone TUI expected to migrate to an app-server-backed runtime?
• If yes, is that a near-term or long-term direction?
• If no, what is the intended long-term model for cross-client live sync?

Why this matters

Right now, users can share a threadId across processes, but live sync is process-local unless clients share the same app-server runtime. In practice this causes confusion:

• TUI in one process + app-server in another process do not share live in-memory turn events.
• Sync is eventual via rollout/resume/read, not true real-time multi-client state.
• Users building custom clients need to know which architecture to target.

What would help

A short guidance note in docs would unblock design decisions:

1. Recommended architecture for true multi-client live sync (today).
2. Whether TUI-over-app-server is an intended destination.
3. If there are planned APIs for cross-process sync/refresh (or if that is explicitly out of scope).

Context

I found app-server transport progress (e.g. websocket support in #10693) and related sync issues, but no explicit roadmap statement tying this to standalone TUI direction.