[BUG] Desktop Code tab (Auto mode): permission prompt never renders — call hangs then is silently killed as "cancelled" on the next message

### Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported with this exact mechanism yet (related: #92053, #85588, #92817, #86478)
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code

### What's Wrong?

In the Claude Desktop app's Code tab, running in Auto permission mode, some tool calls that need classifier escalation to a user-approval prompt never render that prompt anywhere in the UI — no card, no notification, nothing on screen. The call just sits "running." The instant the user sends their next chat message, the pending call is killed and reported to the model as:

> The user doesn't want to take this action right now. STOP what you are doing and wait for the user to tell you how to proceed.

This is not a real user decision — the user never saw anything to approve or deny. The transcript records `toolDenialKind: "cancelled"`, distinct from a real classifier deny (which carries a bracketed reason like `[Self-Modification]`).

Two things make this worse than a simple missing dialog:
1. **It's non-deterministic per call, not purely command-pattern-based.** A `grep` invocation that matched an existing project allow rule (`Bash(grep:*)` in `.claude/settings.local.json`) was silently escalated and killed, even though near-identical `grep` calls against the same file had succeeded moments earlier in the same session/turn.
2. **Toggling "Bypass Permissions" on an already-running session makes it worse, silently.** main.log shows the app accepting the UI toggle and writing config, immediately followed by:
```
[error] [CCD] Failed to set permission mode for session : Cannot set permission
mode to bypassPermissions because the session was not launched with
--dangerously-skip-permissions
```
The UI still shows "Bypass Permissions" as selected, but the running CLI process keeps enforcing its original (stricter) mode — so the user believes they're unblocked and are not, and any subsequent escalated call hits the same invisible-prompt failure above. Confirmed 3x same day across 3 different sessions.

### What Should Happen?

1. Every classifier-escalated tool call must render a visible approval prompt in the Desktop UI — no silent hangs.
2. If a mode switch (e.g. to bypassPermissions) fails server-side, the UI must not show the mode as active — surface the actual error to the user instead of silently keeping the old mode.
3. A killed-by-race tool call should never be reported to the model as a user refusal; it should use an honest "did not complete" message (same class of fix requested in #92053).

### Error Messages/Logs

```
// Failed bypass-mode switch (repeated 3x, 3 different sessions, same day):
2026-09-14 16:16:34 [info] [CCD] LocalSessions.setPermissionMode: sessionId=local_0dcc1e23-9cb2-4097-bdc6-4ae27cc786d5, mode=bypassPermissions
2026-09-14 16:16:34 [info] Config file written
2026-09-14 16:16:34 [error] [CCD] Failed to set permission mode for session local_0dcc1e23-9cb2-4097-bdc6-4ae27cc786d5: Cannot set permission mode to bypassPermissions because the session was not launched with --dangerously-skip-permissions

// Live repro: a Bash(grep) call matching an existing allow rule, silently killed
// the instant a follow-up chat message was sent. No "Emitted tool permission
// request" line for this call in main.log at all (contrast with a normal prompt,
// which does log that line + a matching respondToToolPermission response).
// Session local_faf0804f-... — no setPermissionMode call ever made for this
// session (plain default Auto-mode launch), ruling out the bypass-toggle cause.
```

### Steps to Reproduce

1. Open a session in the Desktop Code tab in Auto permission mode (default).
2. Work normally for a while (tens of tool calls); this is intermittent, not per-command-deterministic.
3. Eventually a Bash (or Agent) call sits "running" indefinitely with no approval card shown anywhere.
4. Send any follow-up chat message.
5. The pending call immediately fails with "The user doesn't want to take this action right now," `toolDenialKind: "cancelled"`, even though no prompt was ever shown to approve or deny.

Separately, to reproduce the bypass-mode issue:
1. Start a session in Auto mode, let it run past the first message.
2. Toggle the session's permission mode to "Bypass Permissions" via the Desktop UI.
3. Check `~/Library/Logs/Claude/main.log` for `Failed to set permission mode` — the UI shows bypass as active, but the underlying CLI process rejects the switch and keeps enforcing the original mode.

### Claude Model
N/A — reproduced across models, this is a permission/UI-layer bug

### Is this a regression?
Unknown

### Claude Code Version
CLI/core 2.1.270; Desktop app 1.52386.6

### Platform
Claude Desktop app (Code tab)

### Operating System
macOS (Darwin 25.6.0)

### Terminal/Shell
N/A (Desktop app, not terminal)

### Additional Information
Related open issues describing adjacent parts of the same failure family, none an exact duplicate of this specific mechanism:
- #92053 — same `toolDenialKind: "cancelled"` / same refusal string, different trigger (session backgrounding/channel loss rather than a missing UI prompt)
- #85588 — "Auto mode silently denies tool actions; denials never surface to the user" (classifier hard-deny, not an unrendered-then-cancelled prompt)
- #92817 — "Bypass all permissions setting not respected during operations" (matches the mid-session toggle failure here, without the specific launch-flag error text)
- #86478 — "bypassPermissions defaultMode and --permission-mode flag ignored; session stays in auto mode"