/remote-control client falls behind on long-running sessions, doesn't recover after reopen

Summary

When activating /remote-control on a long-running CLI session, secondary clients struggle to stay in sync — they get stuck on older messages and don't backfill or catch up to the live state. Closing and reopening the lagging client does not fix it.

Steps to reproduce

1. Run a long Claude Code session in the terminal (many messages of history).
2. Run /remote-control and connect a phone or browser client — works fine.
3. From a second device (e.g. another phone, or browser), connect to the same session via the session list on claude.ai/code or the mobile app.
4. The second client lands on the correct session but is stuck several messages behind the live state.

Expected behavior

Per the docs, all connected clients should stay in real-time sync, and a newly-connected client should backfill the full conversation history.

Actual behavior

• Second client shows older messages only; new messages from the live session don't arrive.
• Closing and reopening the app on the lagging client does not resolve it.
• Same session confirmed (not two different sessions).
• Pattern is reproducible on long-history sessions specifically; fresh sessions sync fine.

Environment

• macOS (Darwin 25.2.0)
• Claude Code CLI, recent version
• Lagging client: iPhone Claude app
• Primary client: terminal CLI on the Mac

Notes

Suspect the long-session backfill path is the culprit — fresh sessions don't exhibit this. Workarounds attempted: close+reopen the lagging app (no effect), confirm same session ID (yes).