Sync deadlocks on a band whose oldest stored records predate kMinPlausibleUnix (revived WHOOP 4.0) #601

What happened?

A WHOOP 4.0 that had been flat since August 2022 never syncs any data. Every sync completes empty, the band page shows "Syncs are finishing with no data in them", and Home stays on "Synced through Thu 1 Jan, 01:00" (epoch 0). Re-pairing, charger restarts and hours of wear make no difference.

Root cause (from a capture with research_playground.py):

1. The band's flash still held records from 13–14 Aug 2022, left over from the official app. GET_DATA_RANGE showed 2022-08-06 / 2022-08-13 / now, and the drain started from 2022.
2. RecordGate drops all of them because they are below kMinPlausibleUnix = 1700000000 (Nov 2023, lib/sync/sync_policy.dart:343). They are counted in droppedBelowFloor.
3. With nothing durable buffered and droppedThisBurst > 0, TrimAckPolicy.evaluate returns blockedNoDurableProgress (lib/ble/ble_state.dart around L719). The HISTORY_END token is never echoed.
4. The band re-offers the same 2022 burst on every connection, so the drain never reaches today's records. Three completed console-only syncs trip EmptySyncTracker, which raises syncClockLost. That status is misleading: the band's RTC was fine, and live records carried the correct 2026 timestamps.

The no-progress gate is right not to trim records the app never stored. But when every drop is below the absolute floor, the batch is genuinely old data, not a wandering clock, and nothing will ever make it bankable. The band stays wedged for good.

Workaround that unblocked it. On Linux, I ran research_playground.py sync (with storage on, so the 2022 data was kept in its whoop.db). It ACKed 9 batches, 4aba… through 28bb… in about 10 s, 40 R12 records plus events from 2022-08-13/14, then reached today. After that, wrist on/off events fired normally. (Pairing from Linux needed a single bluetoothctl session with agent NoInputNoOutput + default-agent; without an agent, bluetoothd cancels the Just Works confirmation and reports AuthenticationFailed.)

Possible fixes:

• If a burst's drops are all below the floor (timeBaseNotWallClock-style signature) and the session's GET_DATA_RANGE oldest is also below the floor, archive the raw frames to raw_archive and treat that as durable progress, so the ACK can go out. Nothing is lost, and the data is never derived.
• At minimum, surface a distinct band status ("Old pre-2023 data on the band is blocking sync") rather than clockLost, whose fix text ("leave it connected… pair it again") can't help here.

Steps to reproduce

1. Take a WHOOP 4.0 whose flash still holds records older than Nov 2023 (e.g. a band left flat since 2022 after its last official-app sync).
2. Pair it in OpenStrap and wear it.
3. Sync. Every sync completes with zero banked records, "Synced through" stays at 1 Jan 1970, and after 3 syncs the band page shows "Syncs are finishing with no data in them".

App version

0.10.x (TestFlight). 0.11.3 wasn't on TestFlight yet, but the floor and the blockedNoDurableProgress gate are unchanged on main at v0.11.3 (1f1025a).

Platform

iOS (TestFlight)

Phone model and OS version

iPhone 16 Pro, iOS 26.6.1

Which band?

WHOOP 4.0

Quick checks

• The official WHOOP app is not also connected to this band
• I've searched existing issues for this