Localise every Android notification string, and let them follow a language change (#867)

[ryanbr]

Closes #867, and covers the rest of the same defect.

Five notifier files built their text from raw Kotlin literals, so every Android notification shipped English in all six locales — including the foreground-service notification that is on screen the entire time a strap is connected. Both notification channels were hardcoded too, and those are visible in system Settings.

22 strings, six locales.

Where the translations came from

Most are the Apple catalog's, moved across unchanged — those strings already existed there, several translated in #866. Seven are new: the four foreground-service phrases, the smart-alarm body, and the two channel descriptions. They follow the register the catalog already uses (informal de/es/pt-PT, formal fr) and are the part of this PR most worth a native reader's eye.

Worth noting the existing Android catalogue is not internally consistent — RECOUVREMENT for Recovery in fr (that is debt collection), de mixing Erholung/Genesung and formal/informal. I anchored on the Apple catalogue instead, which is the better-maintained of the two. Not fixing the pre-existing drift here.

Two locale-staleness bugs, because localising alone was not enough

Localising the strings would have introduced the first of these and left the second:

• postNotification dedupes on connected|backfilling|recovery|battery. None of those changes when the user switches language, and a Service is not re-posted on a configuration change — so the notification would have kept the previous language until the connection or battery state happened to move. On a stable link with a charged strap, that is hours. The locale tag is now part of the key.
• Both ensureChannels returned early when the channel already existed, so a channel's name and description were fixed in the install-time language forever. createNotificationChannel is idempotent and updates them, so the early return is gone. In the service that path runs once per start; in BatteryAlertNotifier every caller sits behind the persisted once-per-crossing gates and Battery drain: diagnose the reconnect loop, and stop re-asking the battery policies every second #886's (SoC, charging) key, so it runs when an alert is actually posted — not on the ~1 Hz live-state tick.

Why the i18n gate never caught it

i18n_audit.py's Android scan roots are ui/ and widget/ only, and its patterns are Compose-shaped (Text(, title=/text= kwargs) — which a NotificationCompat builder chain matches none of.

Adding com/noop/ble and com/noop/notif to the roots alone still found nothing; I verified that rather than assuming it. So the call pattern now also matches setContentTitle/setContentText.

That extension is what surfaced the illness, inactivity and smart-alarm strings — four more literals that were not in #867 and that nobody had noticed. The audit now reports zero hardcoded literals under ble/ and notif/.

Two tests pin the extension: one that a builder chain's literals are found, one that the getString form is not flagged — so it does not get reverted the first time it looks like noise. Removing the pattern makes the first test fail, which I checked rather than assumed.

Verification

• All six strings.xml parse; each gained the same 22 keys, with no duplicate keys, no unescaped apostrophes, and no string carrying more than one non-positional %.
• All 26 R.string references across the five Kotlin files resolve in the default catalogue and in all five translations; format arities match their call sites.
• Every formatted string's specifiers are identical across all six locales — a %1$s where the default has %1$d throws IllegalFormatConversionException for that language only, which no test here would otherwise catch.
• Tools/i18n_audit.py --ci origin/main, its 36 unit tests, and Tools/doc_comment_lint.py pass.

Not compiled. android.yml is disabled so no CI job builds this, and the host cannot (aapt2 is x86-64 only). The resource and R references were checked statically, which catches a missing key or a wrong arity but not everything a build would. Worth a local ./gradlew assembleFullDebug — or enabling android.yml — before merge.