VS Code/Cursor extension: session hangs forever after auto-mode classifier_request_finished (no timeout, webview channel errors silenced)

## Summary

In the VS Code / Cursor extension, sessions freeze mid-run several times per session (4-6x). The hang happens in the auto-mode permission path: the permission classifier request completes successfully, but the decision never reaches dispatch — no `tool_dispatch_start`, no permission prompt, no error, and **no timeout**, so the session waits forever. The UI shows nothing; the only recovery is closing and reopening the chat (which rebuilds the webview channel) and sending a new message. Because the stall usually outlives the prompt-cache TTL, each recovery re-sends the full context uncached (~14% of a session's usage burned per stall).

## Environment

- Extension: Claude Code for VS Code, `cc_version=2.1.220.26d`, `cc_entrypoint=claude-vscode`
- IDE: Cursor on macOS (Darwin 25.5.0)
- Permission mode: auto (Bash commands routed through the `claude-sonnet-5[1m]` classifier, `stage=xml_s1`)
- Plan: paid subscription

## Evidence from `Claude VSCode.log`

Healthy flow (2026-07-26 17:08:29 UTC) — classifier finishes, decision lands, tool dispatches:

```
17:08:25.993 [INFO] [Stall] classifier_request_started reqId=37a6e8cd-... tool=Bash model=claude-sonnet-5[1m] stage=xml_s1
17:08:29.564 [INFO] [Stall] classifier_request_finished reqId=37a6e8cd-... outcome=ok durationMs=3571
17:08:29.581 [INFO] Slow permission decision: 3645ms for Bash (mode=auto, behavior=allow)
17:08:29.591 [INFO] [Stall] tool_dispatch_start tool=Bash toolUseId=toolu_01BQWDA1PsLZBiXdYSL2YRtr permissionDecisionMs=3645
```

Hang, 3 minutes later (2026-07-26 17:11 UTC) — same session, classifier finishes, then nothing, forever:

```
17:11:25.885 [INFO] [Stall] classifier_request_started reqId=1f0bae18-4ea6-47d5-a9f5-d2f0980acf8c tool=Bash model=claude-sonnet-5[1m] stage=xml_s1
17:11:25.955 [DEBUG] [API REQUEST] /v1/messages x-client-request-id=23678dae-fd3f-4140-beb1-28d7558d1888 source=side_query
17:11:28.436 [INFO] [Stall] classifier_request_finished reqId=1f0bae18-4ea6-47d5-a9f5-d2f0980acf8c tool=Bash stage=xml_s1 outcome=ok durationMs=2551
<-- nothing after this: no permission decision, no tool_dispatch_start, no error, no timeout -->
17:14:58.521 [DEBUG] Invalidating session environment cache <-- user closed/reopened the chat to recover
```

The command being classified was `npx vitest ...` (an allow-suggestion for it was logged at 17:11:25.829).

Likely related — every session start logs a webview channel error and then goes silent about further drops, which would explain why the hangs leave no error trace:

```
[WARN] claude-vscode notification channel error: Received a response for an unknown message ID: {"jsonrpc":"2.0","result":{},"id":0}; further channel errors are not logged this session
```

A second symptom of the same channel flakiness observed the same evening (17:28:16 UTC): the webview flipped the session to `state:"idle"` while a subagent (`source=agent:builtin:general-purpose`) was still actively streaming API requests.

## Separate but related: silent give-up on 429

Two other freezes were a different failure: on an account rate limit the extension logs `API error (attempt 1/11): 429 rate_limit_error` but gives up immediately after attempt 1 (`API rate_limit after retries`) and flips the session to idle with no visible error. Request IDs for server-side lookup:

- `req_011CdPNNLX3yrcUAWzXCkjYN` (2026-07-25 19:59 UTC+2)
- `req_011CdQt9Dup3M2oLnovPihZ1` (2026-07-26 15:10 UTC)
- x-client-request-id `4be74d05-690b-46c0-b5e1-d5a84c4b05bf`

## Expected behavior

1. A timeout + retry (or a surfaced error) on the permission-decision path so a dropped channel message cannot hang the session forever.
2. Channel errors should keep being logged (or re-establish the channel) instead of "further channel errors are not logged this session".
3. A 429 with retry budget "1/11" should actually retry with backoff, or clearly tell the user why it stopped.

## Impact

4-6 hard freezes per working session; each recovery requires closing/reopening the chat and re-sending context uncached, burning a significant share of the session's usage quota.

Start with the permission-decision path and the webview notification channel behind the Claude VSCode.log entries, then compare the healthy classifier-to-dispatch flow with the stalled one. Also inspect the 429 retry path described in the issue; done means dropped channel responses and rate limits produce a retry, timeout, or visible error instead of leaving the session idle or hung.

Written by the indexing model from the issue text.