diag: capture the 4.0 GET_BATTERY_LEVEL frame in the strap log (#900)

[ryanbr]

Why

#900 has been blocked for three weeks on one thing: a real WHOOP 4.0 GET_BATTERY_LEVEL COMMAND_RESPONSE of known provenance, to settle whether its zeroed [seq][result] prefix means prefix-absence (the value lives at a fixed offset, the two leading bytes are padding) or a genuine failure. Between zero and one confirmed-real captures exist in-tree; the rest are declared-synthetic fixtures.

The blocker is that a pasted strap log can't currently resolve it: today the log carries only the decoder's verdict (FAILURE(0) … carried a value, the #923 annotation) — which is the very interpretation in dispute — not the raw bytes.

What

On any non-SUCCESS COMMAND_RESPONSE, dump the full raw frame (0xAA..crc32) to the strap log, once per command per connection:

• Full frame, not the post-prefix payload helper — the disputed bytes are the [seq][result] prefix that a payload dump hides. Contiguous-hex format matches the GET_DATA_RANGE raw-frame line (l10n(de): localize the Trends / Explore / Deep Timeline screens (Android) #451) and the aa0f00… form Need one real WHOOP 4.0 GET_BATTERY_LEVEL capture: every in-tree fixture may be synthetic #900's fixtures are quoted in.
• Rate-limited — a 4.0 hits this branch on every battery poll — and re-armed each connection.
• The same line also captures a genuinely-failing command in the same session — the comparison frame the issue explicitly asks for (battery 00 00 vs a real failure's non-zero echo + 0x00).
• Default log, not TestCentre-gated: a battery reply carries no serial/key (unlike the gated GET_HELLO dump WHOOP serial identity: adopt a stable serial id (mirror the Oura path) — multi-strap keystone #1303).

This doesn't decide what the result byte means — it makes a normal strap-log sync self-capture the artefact so the issue can finally be resolved (confirm prefix-absence → per-reply-shape fix; or refute → close #900, relabel fixtures).

Parity

Swift FrameRouter had no twin of the #923 annotation at all — a standing parity gap. It gains both the annotation and the dump, byte-identical to the Kotlin WhoopBleClient text (enumName/CommandNames.label produce the same NAME(raw) label; same result table). Both platforms: log-only, no behaviour/decode change.

Verification

• Swift StrandTests/BatteryResultProvenanceDumpTests (app-build gate): pins the value-carrying annotation, the once-per-connection dump carrying the full frame, and the per-connection re-arm — driven through FrameRouter.handle with the real Need one real WHOOP 4.0 GET_BATTERY_LEVEL capture: every in-tree fixture may be synthetic #900 fixture.
• Android: compileFullDebugKotlin clean locally. WhoopBleClient isn't unit-testable without a full GATT harness (the codebase tests extracted protocol helpers, not the client log path); the Kotlin dump is a structural twin of the Swift-pinned behaviour (mutableSetOf().add() gate).
• On a real 4.0 (the actual point): sync once, read the raw frame (#900 …) line for GET_BATTERY_LEVEL and for any genuine failure in the same session — that pasted log is the capture Need one real WHOOP 4.0 GET_BATTERY_LEVEL capture: every in-tree fixture may be synthetic #900 wants.

Closes nothing on its own; unblocks #900.