Settings: make the analytics consent overlay accessible as a modal dialog

[rosscado]

The first-run analytics consent overlay visually covers Settings, but it is not exposed as a modal dialog and the covered Settings controls remain available in the accessibility tree.

Scope: the analytics participation prompt shown in Settings → General when shareData has no stored decision. This issue covers dialog semantics, keyboard focus and the accessibility of the covered page. Analytics collection, consent copy, onboarding redesign and voice selection are outside scope.

Reproduction and evidence:

1. In a disposable development profile with no stored shareData value, open Settings on General.
2. Observe the full-page “Let's improve Say, Pi together” consent overlay.
3. Inspect the native accessibility tree while the overlay is visible. In the candidate's Chrome for Testing 148 session, the tree exposed background Settings controls and did not identify the consent surface as a dialog. The overlay visually blocked those controls. This was a native accessibility-tree observation, not a completed screen-reader usability test.
4. Verify keyboard behavior as part of the fix: entering the prompt and using Tab/Shift+Tab should keep the active interaction within the consent surface until the user decides. Neither focus containment nor initial/return focus is implemented in the current consent controller.

Source checked at 7f4506e79d451034ef451a375831bbbb8bee72f4:

• GeneralPanel.tsx renders an ordinary section#analytics-consent with no dialog role, modal state or accessible-name association.
• GeneralTab.setupConsent toggles the overlay's visibility and hides only premium/upgrade/devtools sections. It does not manage focus or make the covered header, navigation and preference controls unavailable.
• consent.css makes the overlay fixed, full-viewport and above the page.
• Existing GeneralTab consent tests cover visibility and stored decisions; they do not check modal accessibility or focus.

Expected: the consent prompt's semantic and keyboard behavior matches its visual modality. Actual: the native accessibility tree exposes both the prompt and the covered Settings page without a dialog boundary.

Acceptance criteria:

• The visible consent surface is announced as a named modal dialog with the prompt's purpose available to assistive technology.
• Focus enters the prompt when it opens; Tab and Shift+Tab cannot reach covered Settings controls while it remains modal.
• Background Settings controls are unavailable to assistive technology and interaction while covered.
• Both participation choices remain keyboard accessible, preserve their existing stored meaning and return focus to a visible, meaningful Settings location after the prompt closes.
• Add focused regression coverage and verify the built extension with keyboard navigation and its native accessibility tree.

Deduplication: searched existing issues for consent, analytics and accessibility, and open PRs for consent. No matching Settings-overlay issue was found; #107 concerns accessibility on pi.ai rather than extension Settings.

Filed from the candidate review by Codex.