feat: restructure Settings into accessible tabbed sections

[enaboapps]

Closes #685. Stacked on #693 — base is refactor/settings-optiongroup-684, since this builds on OptionGroup.

The headline change of the v1.0.0-rc.5 milestone, and the first one users will see.

Problem

Settings rendered all 17 AppSettings keys as one unbroken scroll with no navigation. The Pointer group alone stacked five sub-blocks, ~10 disabled-gated fieldsets and three always-visible explanatory paragraphs.

Structure

Five tabbed sections inside the Settings view:

Tab	Keys
General (default)	startWithSystem
Pointer	pointer speed, mouse repeat ×3, key repeat ×2, dwell ×2
Cursor (only when capabilities.cursorOverlay)	overlay enabled, visibility, size, color, crosshairs
Privacy	shareDiagnostics + telemetry consent
Updates	UpdateControls

Cursor splits off along a seam that already existed: the overlay block was separately gated on capabilities.cursorOverlay, so on a platform without overlay support the tab simply does not render, matching the previous conditional exactly.

SettingGroup sections stay inside each panel, so role="region" landmarks, aria-labelledby names and heading structure are unchanged — existing getByRole("region", { name: "Updates" }) queries keep working.

A real Tabs primitive, not a copy of Support's

The Support view's tablist (src/App.tsx:458) looks reusable but is not a complete WAI-ARIA tabs implementation — no roving tabindex, no arrow keys, no aria-controls/tabpanel association. It was deliberately not copied.

Tabs.tsx implements the APG pattern with manual activation:

• Arrow Left/Right and Home/End move focus, with wraparound
• Selection changes only on click or Enter/Space, so focus never moves unexpectedly
• Single tab stop via roving tabindex; panels are role="tabpanel" labelled by their tab

Retrofitting Support onto this primitive is filed separately as #690.

Behaviour preserved

• focusUpdates deep link now selects the Updates tab first, then scrolls and focuses the same #settings-updates region once its panel has mounted (two effects, so the focus target exists when it runs). The region and its accessible name are unchanged.
• Autosave / diff / optimistic flow is untouched. Because it keys off the settings object rather than mounted controls, an edit made on one tab survives switching away and still saves — covered by a new test.
• No AppSettings changes. Pure presentation, per the persisted-schema rule in AGENTS.md.

Tests: 75 → 82

• The 44-line mega-test splits into three per-tab tests.
• The rebase test now switches tabs between its Privacy and Pointer assertions, since those no longer co-render.
• Most other settings tests needed only a selectTab(...) call.
• New: tablist keyboard behaviour and roving tabindex; Cursor tab absent when cursorOverlay is false (previously untested — the browser default is true); banner deep link from a non-default tab; a pending edit surviving a tab switch.
• beforeEach now restores browserState.capabilities, which it did not previously reset, so the new capability test cannot leak into others.

Validation

Check	Result
npm run lint	pass
npm test	pass — 82 tests, 4 files
npm run build	pass
cargo fmt --check	exit 0
cargo clippy --all-targets -- -D warnings	exit 0
cargo test	exit 0

Not verified visually. I could not load the dev server in the available preview browser (it cannot reach this machine's loopback — curl returns 200 where the browser gets ERR_CONNECTION_REFUSED). Verification here is test-level only, so the tab layout and the new .settings-tabs grid are worth a human look, particularly at the narrow <680px breakpoint.

Out of scope

No control redesign. The exact-speed disclosure (#686) and the expandable help notes (#687) remain separate.

🤖 Generated with Claude Code

---

Known regression, tracked in #697

Update failures are surfaced nowhere while another Settings tab is selected. UpdatesSection mounts only when its tab is active, so UpdateControls' <p role="alert"> never enters the DOM on failure, and UpdateBanner deliberately returns null for failed (an existing test asserts that). Start a download from Updates, switch to Pointer, and if it fails the banner disappears with no visual or screen-reader indication until the user returns to the tab. Same gap for cancelled.

Before the restructure the Updates group was always rendered on the Settings page, so the alert fired immediately. This is a real consequence of tabbing the page, not an oversight.

It is not fixed here because every option is a product decision rather than a bug fix: rendering all panels with hidden restores visibility-on-return but not announcement; routing failed through the global banner contradicts an existing deliberate test; and flagging the Updates tab as needing attention is a new affordance beyond this issue's scope. Filed as #697 for that call.

Manual checks that throw are unaffected — runUpdate catches and calls setError, and the app-level error banner renders outside the view regardless of tab.

Review history

Three review passes on this branch; all findings were in the Tabs primitive and are fixed in commits ea86aae, 0d0b4a1 and 0094395:

• Roving tabindex keyed on the selected tab rather than the focused one
• aria-controls pointing at panel ids that do not exist for inactive tabs
• TabPanel unconditionally tabbable, then unconditionally not tabbable, then losing focus to <body> when its tabIndex was removed mid-focus
• The tab stop stranding on a non-selected tab when the banner selected Updates
• A dropped .settings-panel:focus-visible rule

Both regression tests added in 0094395 were verified to fail with their fix reverted. An earlier version of the panel-focus test was vacuous — it mutated browserState without triggering a render — and now drives a real onState event.

Tests: 82 → 87.