/remote-control: mobile session locked out when desktop has an unanswered permission prompt

Summary

When using /remote-control from the mobile app, if the desktop session is sitting on a tool-use permission prompt (the "Allow once / Allow for session / Deny" picker) that you didn't answer before switching devices, the remote session is effectively frozen. Mobile lets you keep typing and queueing messages, but none of them deliver, and there is no way to surface or respond to the pending permission prompt from mobile. The only recovery is to physically return to the desktop machine, hit Esc, and re-issue the prompt.

Steps to reproduce

1. On desktop, start a task that will trigger a tool-use permission prompt (e.g. an Edit/Write to a path that isn't pre-allowed).
2. Before answering the "Allow once / Allow for session / Deny" prompt, walk away from the desktop and open the Claude mobile app.
3. Open the same session via /remote-control (Desktop 2 in my case).
4. Type any follow-up messages from mobile (e.g. "I approve continue", "continue").

Expected

Mobile should either:

• Surface the pending permission prompt with the same Allow once / Allow for session / Deny choices so the remote user can unblock the session, or
• Show a clear "session is blocked on a permission prompt on the desktop client — cannot proceed remotely" state instead of silently queueing input.

Actual

• The pending permission prompt is invisible on mobile.
• Messages typed on mobile appear to send but stack behind the unanswered prompt and never get processed.
• Session stays frozen until you return to the desktop, press Esc to dismiss the prompt, and resubmit.

Impact

This defeats a big chunk of the value of /remote-control — any task that hits a tool needing approval will brick the remote session, and the user has no signal from the mobile UI that this is what happened. Easy to lose work or waste time waiting on a session that will never resume.

Environment

• Claude Code CLI on Windows 11 (desktop side, PowerShell)
• Claude mobile app (iOS) using /remote-control
• Tool was a Write/Edit to a project file that wasn't on the auto-allow list

Suggested fix direction

Either forward the pending permission prompt to the remote-control client, or have the desktop auto-reject queued input from a remote client while a permission prompt is pending and surface that state on mobile.