[BUG] iPadOS: session stuck in "turn in flight" after queueing messages — queue undismissable, later responses never render

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

On iPadOS, queueing several messages while a response is still generating leaves
the conversation permanently stuck in a "turn in flight" state. It does not
recover on relaunch.

All of the following are present at once:

- Four queued message chips sit below an assistant response that already
answered them. They were delivered and answered server-side, but the client
still renders them as unsent.
- The ✕ on each chip is inert — no tap feedback, no dismissal.
- The composer placeholder is stuck on "Queue for after this turn…" and the
send button is stuck as a stop (■) square.
- A loading spinner runs continuously in the bottom-right corner.
- The most recent turn shows "7s · thinking…" indefinitely. The assistant did
produce a full response — it exists server-side — it was simply never
rendered in the client.

So the client and server disagree about what has already happened in the
conversation, and the client is behind.

Force-quitting and relaunching does not clear it, so this is not purely
in-memory client state.

### What Should Happen?

Expected: when the turn completes, queued messages either send — rendering as
sent user messages above the reply — or stay dismissable via ✕. The composer
returns to normal, send returns to send, the spinner stops.

Actual: the queue never reconciles, ✕ does nothing, the session permanently
believes a turn is in flight, and subsequent assistant responses are generated
but never rendered. The conversation becomes unusable.

### Error Messages/Logs

```shell

```

### Steps to Reproduce

1. Open an existing Claude Code session on iPadOS.
2. While a long response is streaming, send 3–4 short messages in quick
succession so they queue.
3. Wait for the response to finish.
4. Observe: chips remain, ✕ inert, composer stays in queue mode, send stays a
stop button, spinner never stops.
5. Force-quit and reopen. The state persists.

### Claude Model

None

### Is this a regression?

I don't know

### Last Working Version

_No response_

### Claude Code Version

mobile app, not the CLI

### Platform

Other

### Operating System

Other

### Terminal/Shell

Other

### Additional Information

- Claude app on iPadOS
- Claude Code (web) session, model Opus 5
- claude --version: N/A — mobile app, not the CLI
- Occurred 2026-09-09, ~23:13–23:21

No source files or tests are named. Reproduce on iPadOS by queueing messages during a streaming response, then force-quit and reopen to inspect the persisted session state. Done means queued messages reconcile as sent or remain dismissible, the composer and send control return to normal, and later assistant responses render.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.