fix(ble): decode + correlate GET_CLOCK on WHOOP 5/MG (#827)

[jbergler]

Summary

• #827: "Clock latched" read no forever on every WHOOP 5/MG strap — GET_CLOCK's reply is sent on connect (Today hero: keep ring labels/pills on one line (oversized card, #74) #78) but was never decoded for that family, and the documented GET_DATA_RANGE fallback (on DEVICES, the strap says Clock latched: no #261) is also dead since GET_DATA_RANGE is never sent to a 5/MG strap.
• Adds a GET_CLOCK debug probe (mirrors GET_EXTENDED_BATTERY_INFO / ENTER-EXIT_HIGH_FREQ_SYNC: opcode mismatch between two independent RE sources (87/85/86 vs 98/96/97) #592/Add read-only GET_BODY_LOCATION_AND_STATUS probe #690) to capture the raw reply from real hardware, then decodes it in decodeWhoop5CommandResponse using the same payload-relative offset as WHOOP4 (the "+4 rule"). Confirmed against two real WHOOP 5.0 captures 62s apart whose decoded clocks advanced by exactly that gap — locked in as a regression test.
• FrameRouter now publishes the decoded value on LiveState.strapClockUnix, which the Devices/Test Centre "Clock latched" readout falls back to when the WHOOP4-only log-scraped signal is absent.
• Cleanup: configureCollectorFamily() previously forced an identity clockRef (device==wall) for every 5/MG connection instead of ever using a real GET_CLOCK correlation — so a genuinely drifted 5/MG RTC was invisible, and the drift-triggered SET_CLOCK re-issue (ClockPolicy.shouldSetClock) only ever ran on the WHOOP4 branch. Both families now share one applyClockCorrelation(from:) path. Since both now write into the same clockRef, added a disconnect-time reset so a stale correlation from one family can't leak across a same-session strap-family switch.
• Ports the same GET_CLOCK decode fix + debug probe to Android (Framing.kt, WhoopBleClient.kt, DevicesScreen.kt), per the parity contract. Not ported: the clockRef correlation cleanup — Android has no GET_CLOCK-based clockRef for either family (it always derives a rough correlation from GET_DATA_RANGE's newest banked record, see beginBackfill's #700 comment), so there's no WHOOP4 pattern for WHOOP5 to diverge from there; building that from scratch would be new work, not a port of this cleanup.

Verification

• swift build / swift test pass (WhoopProtocol package).
• Full macOS xcodebuild -scheme Strand build succeeds; SetClockPayloadTests, ConnectionTestModeEmissionTests, BackfillContinuationTests, AlarmReadbackDecodeTests all pass.
• Android: ./gradlew compileFullDebugKotlin succeeds. Could not run ./gradlew testFullDebugUnitTest in the dev sandbox (missing macOS aapt2 entry in verification-metadata.xml, pre-existing/environment-only, unrelated to this change) — please run on a machine where that works before merge.
• Real hardware, confirmed on both a probe capture and a live connect:
  • Two #827 probe captures 62s apart: decoded clocks 1785050961 → 1785051023, advancing by exactly 62s.
  • A live connect on 2026-07-26 (post-cleanup build) logged Clock correlated: device=1785052722 wall=1785052723 — cross-checked against the raw captured frame by hand, exact match. The subsequent historical offload logged rows landed on 2026-07-26 · clock ref in sync, confirming the real correlation (not the old forced identity) drives correct date placement.
  • Confirmed the drift-triggered SET_CLOCK re-issue correctly did not fire at 1s of drift (under the 2s ClockPolicy threshold).
  • A strap restart mid-session triggered a clean reconnect + fresh re-correlation, with no stale leftover value — validating the new disconnect-time clockRef reset.

Test plan

• Swift package tests
• macOS app build + targeted StrandTests
• Android Kotlin compile
• Real WHOOP 5.0 hardware: probe captures, live connect, strap restart
• Android unit tests (please run on a machine without the sandbox's aapt2 verification gap)

Fixes #827

[ryanbr]

Excellent work — two captures 62s apart advancing by exactly 62s is the right kind of proof, and the parity section (port the decode, state why the clockRef cleanup does not port) is exactly the contract.

One blocker, and your own summary has the evidence for it.

The 5/MG used to get an identity clockRef at connect, so live persistence always worked. Now it gets nil until GET_CLOCK replies — and the #700 fallback chain cannot rescue a 5/MG: after 3 retries it needs strapNewestTs, which as you note is never populated there because GET_DATA_RANGE is never sent to that family. So a 5/MG that does not answer GET_CLOCK now has clockRef == nil forever, and Collector (line ~160, guard clockRef != nil) buffers, drops past maxPreClockFrames, and persists nothing. Silent total loss of live capture.

Not hypothetical: #700's own comment records a real strap doing exactly this ("GET_CLOCK sent, no reply"). And the retries only fire inside beginBackfill(), so a live-only session that never offloads gets a single attempt.

Suggest: when retries are exhausted and strapNewestTs is nil, install the identity ref on .whoop5 — still legitimate there (real-unix live timestamps, the original justification), and it keeps the real correlation whenever GET_CLOCK does land.

Minor: android.yml is disabled, so nobody's CI will run the Android tests you flagged — that checkbox stays unticked unless someone runs it locally.