[BUG] iOS Code tab: session list stays "Waiting for you" after /clear, while the session view correctly shows Context cleared

Summary

After /clear is run on a session that was waiting for user input, the iOS app's Code tab session list keeps showing that session as Waiting for you with the raised-hand status icon — indefinitely.

The session detail view is correct. Opening the session shows /clear and the Context cleared divider, with an empty composer and no pending prompt. So the app has received and rendered the clear; only the session-list row is stale.

This makes the list unusable as a triage surface: rows that claim to need attention don't, and the only way to find out is to open each one.

Steps to reproduce

1. From the iOS Claude app, attach to a Code session via Remote Control (mine runs in the VS Code extension).
2. Drive the session to a state where it is waiting on user input — the session list row shows the raised-hand icon and Waiting for you.
3. Run /clear in that session (I ran it from the iOS app itself; the screenshots below are that path).
4. Open the session — it correctly shows Context cleared and an empty composer.
5. Go back to the Code tab session list.

Expected

The session list row drops the Waiting for you state once the session is cleared, since nothing is pending any more — it should fall back to whatever the idle/ready presentation is.

Actual

The row still shows the raised-hand icon and Waiting for you. It does not self-recover.

Screenshots

Both taken at 7:50, seconds apart, same session.

Session detail — correct. /clear was accepted, Context cleared rendered, composer empty:

_(screenshot 1 — session detail — attached below)_

Code tab session list — stale. The same session still shows the raised-hand icon and Waiting for you:

_(screenshot 2 — Code tab session list — attached below)_

Related issues

• #92114 — iOS Code tab: completed/idle sessions show gray status dot instead of green. Nearest sibling: also the iOS Code tab session-list status indicator disagreeing with the session's real state. Possibly the same list-row state derivation.
• #90711 — Remote Control: busy indicator never clears after /compact. Different indicator (busy vs. waiting-for-input) and different surface (session view vs. list), but the same shape: a slash command that ends the turn without an assistant entry leaves a client-side state flag set. That issue's hypothesis is that the client clears state on a relayed assistant turn-end; /clear likewise produces no assistant turn.
• #89761 — Mobile app and IDE chat never refresh when a session is advanced externally. Broader client-staleness mechanism. Distinct here in that my session detail view did update correctly — only the list row lagged — so this is not the general "surface never refreshes" case.

Environment

| | |
|---|---|
| Client | iOS Claude app, Remote Control |
| Host | VS Code extension (Windows 11) |
| Model | Opus 5 |
| Regression? | Unknown — first noticed recently, no known good version |

Additional notes

I have not checked whether the row clears if the app is force-quit and relaunched, or whether the same staleness occurs when /clear is issued from the host (VS Code) rather than from the phone. Happy to test either, or to record a screen capture of the transition if that would help.