ble: stop the auto-continue empty-offload storm — guard 2a on real rows

[ryanbr]

Fixes #1144. From a real WHOOP 4.0 capture (9.3.2-staging) I analysed today.

The bug (measured)

The offload auto-continue (#364/#451) fired 7 bursts of 24 empty offloads (~168 in 27 min), each with a 2M-PHY round-trip — a sustained battery/radio storm (the same capture showed ~4%/hr overnight background drain).

Root cause: shouldAutoContinue guard 2a (strapNewest − frontier > 300s → return true) fires regardless of whether the offload pulled any rows. When the strap advertises a newest ahead of our frontier but the offload returns chunkRows=0 (a phantom gap), the frontier can't advance without rows, so newest − frontier stays > 300s and 2a re-fires to the full 24 cap. Guard 3 (lastTrimAdvanced) doesn't catch it — the trim u32 climbs on empty ENDs. Only guard 2b checked rows.

The fix

Both platforms (WhoopBleClient.shouldAutoContinue + Swift BackfillContinuation.shouldAutoContinue, kept byte-for-behaviour): an empty session (rowsPersistedThisSession <= 0) never auto-continues, whatever the reported gap — making 2b's row check the one authority for both cases. Each 24-spin collapses to a single empty offload + fall back to the 15-min floor. Healthy deep backlogs persist 245–251 rows/chunk, so they're unaffected.

Verification

• Kotlin BackfillContinuationTest — green locally (24 tests, incl. the new phantom-gap regression).
• Swift shouldAutoContinue — validated via an isolated harness (StrandTests runs only under xcodebuild): happy-path continue, phantom-gap stop, stale-epoch-with-rows continue, caught-up stop all correct.
• App targets (macOS + iOS) compiling via app-build.
• BLE-path change: needs a real-strap validation pass before release — but this is strictly more conservative (adds a stop condition; can't cause a new spin), and the reporter (me) has the exact repro.

Tests updated: continue-expecting cases now pass rows>0 (a frontier can't advance with 0 rows, so the old rows=0 happy-paths modelled an impossible state).