[Desktop, Windows] Accessibility: 'View usage in Settings' opens Settings dialog without moving keyboard/screen-reader focus into it

# Claude Desktop (Windows): "View usage in Settings" opens the Settings dialog without moving keyboard focus into it

**App:** Claude Desktop 1.52386.3.0 (MSIX, x64), Windows 11 Pro 10.0.26200
**Assistive technology:** NVDA
**Area:** Code tab, usage popover → "View usage in Settings"

## Steps to reproduce
1. With NVDA running, open the usage popover (usage ring / "Usage").
2. Activate the arrow link "View usage in Settings".

## Expected
The Settings dialog opens on the Usage section and keyboard/screen-reader focus moves into the dialog
(WCAG 2.4.3 Focus Order; ARIA dialog pattern: focus moves into a modal dialog when it opens).

## Actual
The dialog opens visually, but focus stays behind it. NVDA cannot reach the dialog content until the user
clicks inside the dialog once with the mouse. For a keyboard-only or blind user the dialog is effectively
unreachable.

## Root cause (from the shipped bundle `resources/ion-dist/assets/v1/`, minified names)
1. **The Settings dialog opts out of initial focus.** In `shared-20-bCuAiMba.js` the settings modal renders a
Base UI `Dialog.Popup` with `initialFocus: ex`, where `function ex(){return!1}`. Returning `false` tells
Base UI not to move focus when the dialog opens.
2. **The fallback only covers one case.** An effect focuses the popup only when the settings content chunk
goes from not-loaded to loaded *and* `document.activeElement` is `null` or ``:
`!t&&e!==null&&S&&(document.activeElement===null||document.activeElement===document.body)&&M.current?.focus()`.
When the chunk is already loaded, or when something else still has focus, nothing moves focus.
3. **The usage popover is not closed first, so focus is never on ``.** In `c51de9054-DCjU9aJk.js` the
popover's `onSettingsClick` only records analytics (`Te=t(()=>{Q("settings")},[Q])`), whereas
`onUpgradeClick` and `onBuyCreditsClick` also close the popover (`Z(!1)`). The link handler in
`c5afb3665-DoubTiQ4.js` then calls the settings store's `open("usage")`. Focus therefore remains on the
"View usage in Settings" link inside the popover, which now sits under a modal dialog, so condition 2
never holds.
4. The same `open("usage")` path without focus handling exists in two other entry points:
`c2d611398-I-hhE0OY.js` (usage summary link) and `cddc0f8fa-DG9nySe8.js` (`At()`, icon button
"View usage in Settings"). Note that the store's `focused` option (`open(section, subpath, {focused:true})`)
only changes the dialog header presentation; it does not move keyboard focus.

## Suggested fix
- Let the Settings dialog take initial focus (remove the `initialFocus` override returning `false`, or focus the
popup/first control on open) whenever it is opened by a user action, regardless of the current
`document.activeElement` or whether the content chunk was already loaded.
- Close the usage popover in `onSettingsClick`, as the other popover actions already do, and make sure the
popover's focus return to its trigger does not pull focus back out of the dialog.
- On closing Settings, return focus to the usage trigger.

## Notes
The root cause was established by reading the shipped bundle; the symptom is reproduced by the reporter with
NVDA. No live instrumentation was run.

## Claude Code context
- Reported from a Claude Code session in the Code tab of Claude Desktop on Windows; the bug was hit there.
- Claude Code bundled with the app at the time of the report: 2.1.266 (Claude Desktop 1.52386.3.0).
- Rechecked on Claude Desktop 1.52386.6.0 with Claude Code 2.1.270: the same code is still present
(`initialFocus` returning `false` in `shared-20-bCuAiMba.js`, the fallback that only focuses the dialog when
`document.activeElement` is ``, and `onSettingsClick` in `c51de9054-DCjU9aJk.js` recording analytics only).

Start by reproducing the Windows issue with NVDA from the usage popover, then inspect the settings dialog and usage entry points in shared-20-bCuAiMba.js, c51de9054-DCjU9aJk.js, c5afb3665-DoubTiQ4.js, c2d611398-I-hhE0OY.js, and cddc0f8fa-DG9nySe8.js. Done means Settings receives focus when opened from each entry point, the popover does not reclaim focus, and closing Settings returns focus to the usage trigger.

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