[ryanbr]

Follow-on to #1706, which now persists the raw readback frame but gave no way to obtain one.

The gap

The GET_ALARM_TIME readback was reachable only by arming. An install with the alarm switched off could not produce the evidence that would explain what its strap reports — which is exactly the state of the account whose 2045-06-10 readback prompted the issue.

iOS had getStrapAlarm() for this, but it had never had a caller on either platform. So porting the function alone would only have added dead code to a second platform. This is the function plus a way to press it.

What this adds, both platforms

A "Check what the strap has stored" button on the strap firmware-alarm card. The reply lands on the same GET_ALARM_TIME branch an arm's follow-up read uses, so it persists the reported epoch and the raw bytes for the debug export.

	Android	iOS
Button	StrapAlarmCard	SmartAlarmView, same card and copy
Shown when	connected (bonded)	always, in the 4.0 branch
Command	WhoopBleClient.getStrapAlarm()	BLEManager.getStrapAlarm() (existing)

The gating difference is deliberate and commented at the call site. Gating is free on Android because that card already observes LiveState. SmartAlarmView does not, and this codebase deliberately keeps live out of parent views so a 1 Hz HR tick cannot re-render them. getStrapAlarm() no-ops and logs when nothing is connected, so always showing it costs one ignored write rather than a per-second re-render of the whole alarm screen.

Not family-gated

Unlike armStrapAlarm, which refuses on a 5/MG — but that is defensive, not a feature. send() already no-ops when disconnected and only the 4.0 branch decodes the reply. Both buttons live in the 4.0 branch of their card, so nothing captures a 5/MG frame today; a caller could be added there if that layout ever needs recording, without changing the method.

An earlier draft of the doc claimed the 5/MG raw frame was "the whole point of the button" — a path its only caller cannot reach. The doc now says what the code does.

Practical note for #1706

The reporting account has a 5/MG active and a 4.0 paired, and the 2045 readback came from the 4.0. The button appears in the 4.0 branch, so that user needs to be connected to the 4.0 for it to show. It is "connect your 4.0, then press this", not "press this".

Strings

Two strings. Android: all seven values*/strings.xml, named without the l10n_ prefix — in that file the prefix marks a key the extractor generated with a content hash, so a hand-written key wearing it would look machine-extracted. iOS: all ten locales in the catalogue (pl is ratcheted, so a missing one hard-fails the audit).

The catalogue was edited as text, not re-serialized. json.dumps(indent=2) expands that file's hand-compacted entries and turns a two-string addition into a 3,426-line diff — the first attempt did exactly that, and the audit still passed on it, which is what made it dangerous. The kept version is six added lines in the neighbours' own style, re-parsed to prove it still loads.

Verified

• 4,725 Android tests, 0 failures with --rerun-tasks --no-build-cache
• Tools/i18n_audit.py --ci clean — it correctly rejected an earlier hardcoded Android help string, now localized
• lintVitalFullRelease clean
• app-build green on both legs, which is the only thing that compiles SmartAlarmView

One note for whoever runs the build

lintVitalFullRelease must be invoked separately from the debug test tasks. Combining them trips a Gradle task-wiring validation error — syncRoomSchemaSnapshot consumes kspFullReleaseKotlin's output without declaring the dependency. I confirmed it reproduces on unmodified main with the same command in an isolated worktree, so it is pre-existing and unrelated to this change. Probably worth its own issue; CI evidently uses separate invocations, which is why it has not surfaced.