VS Code extension: AskUserQuestion picker steals keyboard focus on mount even when its chat tab is hidden (mount-focus lacks the document.hasFocus gate the 500ms step has)

## Environment
- Claude Code VS Code extension 2.1.235, VS Code 1.133.0, Windows 11

## What's wrong

When an `AskUserQuestion` (or permission) prompt mounts in a chat webview, the picker immediately focuses its first option:

```js
se(()=>{let k=f.current;if(!k)return;k.querySelector('[role="radio"], [role="checkbox"]')?.focus()},[n]);
```

This effect has **no visibility/focus gate** — it runs even when that chat's tab is a *background* tab (webviews are retained, so the hidden document keeps executing). Because a webview iframe can pull keyboard focus in VS Code, the mount steals the caret from whatever the user is typing into **in a different tab of the same window** — another Claude chat's composer included.

Notably, the very next effect in the same component IS gated correctly: the 500 ms "focus the primary button" step checks that the webview document has focus before acting. The mount-focus of the first option lacks the same condition.

## Observed (element-level UIA focus trace)

While dictating into chat A's `Message input`, a background chat B received an `AskUserQuestion`. Within ~100 ms of the ask arriving, system keyboard focus left chat A's composer and landed inside chat B's (non-visible) webview document — zero clicks, no tab change, window title unchanged. The user's in-flight text went to a non-editable target.

The follow-on hazard is worse than lost keystrokes: with keyboard focus silently inside an invisible picker, a stray Space/Enter selects an option and auto-advances, and a stray **Escape rejects the ask** — we have separately observed a pending AskUserQuestion resolve as "User rejected tool use" with no click anywhere near the picker.

## Suggested fix

Gate the mount/question-change focus effect the same way the 500 ms primary-button step is gated — only focus the option when the webview document has focus (or the panel is visible/active). A user landing on the tab later still gets keyboard-ready options via the existing focus management.

## Related

- #63558 fixed this exact principle for the CLI ("Permission prompt immediately steals focus while typing") — this is the VS Code webview/cross-tab variant.
- #88465 (file-preview reveals taking focus) is a sibling report; together they cover the two paths a working/background session can yank the caret from the tab the user is typing in.

Search the VS Code extension source for the AskUserQuestion picker and the mount-focus effect shown in the report. Compare it with the adjacent 500 ms primary-button focus effect, then verify that a prompt mounting in a background chat does not move focus while an active chat still receives the intended focus behavior.

Escrito por el modelo de indexación a partir del texto del issue.