[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).