TalkBack, 1 of 10: Add accessible transient message live regions

[eliotcougar]

Summary

First of ten focused TalkBack PRs: make transient feedback accessible without turning visual Toast/Snackbar messages into interactive accessibility targets.

Foreground messages use the existing Compose Snackbar host and mirror their text to a separate live region by default. Background feedback uses a regular Android notification, not a deprecated custom Toast fallback.

Foreground feedback

• Keep the visual Snackbar accessibility-inert and without a click action.
• Mirror all normal, success, error and info messages to a locale-tagged polite live region by default. Callers no longer need to opt in, and cannot accidentally disable the live-region mirror with a null priority.
• Retain assertive feedback for service-start success, service-stop success, service-start failure and errors preventing a requested start.
• Ordinary feedback, including a foreground "Starting service" message, uses the polite default.
• Ignore blank messages and suppress only rapid duplicates with the same text and priority. A priority change is a new update.
• Retain the short-lived, stable live-region node and the two-frame text-publication sequence; hide it from navigation when idle. No focus requests or handcrafted accessibility announcement events are used.
• This is a live-region update mechanism, not a speech queue: the accessibility service controls interruptions and coalescing.

Subscription/config and asset update results use localized count plurals. Asset download-start feedback is also mirrored. All related resources cover the nine maintained locales.

Service identity

The daemon supplies the name of the profile whose configuration actually started in the success-event payload. The UI does not re-read the current selection, which may already point at another server.

The visible success Snackbar stays unchanged. Its accessible text adds "Now connected to [server name]". Background success notifications use the same enriched wording. Empty or missing names fall back to the ordinary success message, rather than guessing from the current selection.

Background fallback and channels

• Send service results to the UI with acknowledgement; if no resumed consumer handles a result, post background feedback.
• All transient fallback messages share one notification ID. Every new message replaces the previous message; "Starting service" has no special replacement policy.
• Use an expandable, auto-cancel notification opening the main screen, with a ten-second platform timeout on Android 8/API 26 and later.
• Respect notification permission and app/channel settings; do not bypass a user's decision to disable notifications.
• Cancel stale fallback feedback when a new message is successfully delivered in the foreground.
• Use dedicated localized channel titles, including "Connection checks" and "Other notifications". Rename existing channels when necessary without resetting user-controlled importance, sound or vibration.
• Keep channel API calls inside a locally checked API-26 guard; no lint suppression is added.

Android 7/API 24-25 automatic expiry is intentionally not implemented in this PR; the notification remains replaceable and dismissible there.

Per-app information and PR boundaries

The per-app information action opens an OK-only modal containing the existing explanation, without a title. There is no remaining per-app info-toast call in this branch.

The identical modal is also present in #6164 so either focused PR can be merged independently. Its callback boundary is aligned to avoid a conflict with that PR's switch changes. No per-app row/toggle semantics are imported here.

The remaining accessibility work is split across TalkBack PRs 2–10. This PR does not implement their list, Settings, navigation or connection-testing semantics, suppress native control roles, or replace genuine toggle behavior.

Foreground lifecycle handoff gaps and broader stop/restart sequencing remain separate follow-up work; this PR does not claim to repair those lifecycle issues.

Validation

• :app:testPlaystoreDebugUnitTest — 74 tests passed.
• :app:compilePlaystoreDebugKotlin and :app:assemblePlaystoreDebug — passed.
• Regression coverage includes default mirroring for every message type, blank/duplicate handling, priority changes, delivery fallback, notification permission/channel decisions, and formatting an immutable started-server name after selection changes.
• :app:lintPlaystoreDebug — the new NotificationHelper API errors are resolved. Four pre-existing upstream API errors remain in RootManager, RootShell and the two base theme resources.
• All 45 focused-PR pairs merge cleanly in both orders. Combining all ten PRs forward and backward produces the same tree.
• The local combined result passes 86 unit tests and builds successfully.
• Android 11 emulator, combined build: the per-app modal contains only its explanation and OK; Tab/Enter dismisses it. Existing lab subscription data was preserved.
• git diff --check — passed.

Verified

• Tested on a real device with TalkBack on.

Android references

• Compose semantics and live regions
• Notification channel creation and updates

[eliotcougar]

I tested the whole set on my Pixel 9 pro with Android 17. The AI tested it on Android 13 and 15 VMs.
The individual PRs have no intersections and can be merged in any order and combination.

This PR is the largest as it expands the Toast notification system and makes it compatible with accessibility mode. As a result, it touches every activity that can emit a Toast notification. Unlike the previously rejected PR, it doesn't use the deprecated direct announcements or other workarounds. Instead, it relies on a live-region and a regular notification channel fallback, and follows the official Android accessibility guidelines.

Other PRs are focused on individual Activities and are much smaller and easier to review.

[eliotcougar]

GPT-6 Astra worked the entire day making the accessibility PR set better and review-friendly as much as possible.
The new model seems to be less prone to overengineering and implementing useless protections against situations that don't happen.
Spent 65% of the weekly credit and a full phone battery.
I'm going to test all 10 combined (with 4,069 additions and 677 deletions across 82 files, including regtests) tomorrow after a good night sleep, and fix any remaining UI/UX problems.

There are several small general UI fixes here and there in the accessibility set. I'm not yet sure if I should separate them into tiny separate PRs... They are tiny...