[ryanbr]

The bug (found tracing a v10.1.1-staging strap log)

The Android backfiller clock correlation is re-seeded on every offload from (strapNewestTs, now). WHOOP4 doesn't re-fetch GET_DATA_RANGE at each offload (only WHOOP5 does), so strapNewestTs stays frozen between fetches while now advances — inflating the offset by all the elapsed wall time since the last fetch. Straight from the log:

13:49:33  device=1787017727  offset 46s      ← true RTC skew, right after GET_DATA_RANGE
14:20:01  device=1787017727  offset 1874s    ← device frozen, offset grew with wall time
14:49:09  device=1787017727  offset 3622s
14:50:18  device=1787017727  offset 3691s     ← ~1h of pure staleness

The offset should be the strap's constant RTC skew (~46s), not a number that climbs with elapsed time.

The fix

Capture the wall clock at the same instant strapNewestTs is read from the GET_DATA_RANGE reply, and pair that with the device time when seeding the correlation — instead of a later now. The offset then reflects the true skew regardless of how stale strapNewestTs is. No extra BLE round-trip.

Scope (deliberately narrow)

• Stored offload data is unaffected — type-47 historical records carry their own unix timestamp, so the correlation offset is a no-op for them. This is not the cause of the offload stalls (those are benign strap-side chunking + idle-cap, handled by auto-continue Sleep presentation: stitch short mid-night wakes into one displayed night (+ motion-aware wake classification) #364/l10n(de): localize the Trends / Explore / Deep Timeline screens (Android) #451).
• What it does fix: the REALTIME_RAW_DATA fallback stamping, and — concretely — the strap-log diagnostics the inflated offset was making unreadable (it read as a ~1h clock skew that isn't real).
• Android-only: Swift reads the real clock via GET_CLOCK and derives its strapNewestTs fallback once (sticky), so it has no per-offload re-seed inflation. No parity change.

Validation

Compiles clean (compileFullDebugKotlin). BLE path → hardware-confirmed by a strap log showing the offset holding at the true ~46s skew across an offload burst (per CLAUDE.md's BLE-validation rule; no CI/unit coverage for the CoreBluetooth path).