fix(oura): hand the store a record's beats at once so beat order stops being 0

[pipiche38]

Fixes #1072. Root cause for #823 — that issue's symptom is still live on main today.

Branch: fix/oura-rr-ord-batching-1072 (based on main @ 7c7b3f0c, commit ee79530e)
Base: main — the defect is byte-identical on main, not an integration-branch regression.
Depends on: #1071 (merged as #1076, fddf9038). Required: while two optical channels were
interleaved in one stream, ord would have numbered an interleaving of two sensors measuring the
same beats, which is not an emission order.

No migration. No schema change, no stored-value redefinition — this is a call-site fix. The
column and its counter have been correct since v30.

---

The bug

v30-rr-ord added rrInterval.ord so a second's beats could be read in emission order rather
than magnitude order. The store-side machinery is right. On the Oura path ord is written 0 on
every row: measured in a real database, 575,630 / 575,630 rows — the value 0, not NULL (NULL
would mean "pre-v30, never recorded"; 0 means the write path ran and computed 0 every time).

The counter is batch-local by design — one insert is the only place the order still exists — and
the v30 comment says so:

"Same batch-local caveat as seq: a second split across two live flushes restarts ord at 0 …"

Strand/BLE/OuraLiveSource.swift enqueued one event per batch:

case .ibi(let ibi):
    …
    if let ts = driver.unixSeconds(forRingTimestamp: ibi.ringTimestamp) {
        enqueue([e], ts: ts)          // ← single-element array
    }

Every batch therefore held exactly one R-R row, ordByTs was always fresh, and every beat got
ord = 0. android/…/ble/OuraLiveSource.kt had the identical shape (enqueue(listOf(event), ts)).

Why it matters

Five to six beats share each timestamp (records arrive ~2.8 s apart). With ord tied, reads fall
through to the (rrMs, seq) ordering in the primary key — sorted by value. RMSSD is built
entirely from successive differences, and sorting a sequence minimises those differences by
construction. That is precisely the bias #823 describes; on that issue's own example, magnitude
order reads 12.72 ms against 34.85 ms in emission order.

The fix

All of one record's beats carry that record's ring time, so grouping the anchored .ibi events of
one ingest by their resolved second and enqueuing each group once hands the store a record at a
time — and ord becomes their real emission order.

• Grouping is a pure OuraStreamMapping.batched (Swift Packages/WhoopStore, Kotlin
  com.noop.data), so the ordering logic sits where package CI covers it instead of only in
  app-target code that no default CI builds.
• Applied on the live path (ingest / emit) and where parked beats are released after the 0x42
  anchor lands (drainPendingAnchorEvents), which is where a drain's first beats go.
• The .ibi arm now owns only the live readout and parking; it no longer enqueues.

Deliberately unchanged:

• an IBI still never advances the resume cursor (noteStoredHistoryRingTime) — a live beat could
  otherwise leap maxStoredRingTime to ~now during a force-stopped drain and permanently skip
  un-drained backlog;
• unanchored beats still park rather than being stamped with a guess;
• .sleepPhase stays outside the batch — it is assembled at record level by the hypnogram assembler.

One behaviour does change, and it is a recovery

seq (v24) is batch-local for the same reason ord is, and it exists precisely so two beats sharing
an interval value in one second survive as distinct rows. Insert-per-beat recomputed seq = 0 for
the second beat, so it collided on (deviceId, ts, rrMs, seq) and was silently dropped by
ON CONFLICT DO NOTHING. Batched, both are stored.

So a post-fix night holds slightly more R-R rows than a pre-fix one — real beats that were being
lost, not duplicates invented. Worth knowing when reading coverage numbers against the pre-fix
baseline in #1071's validation: a small rise there is expected and is not a regression. Pinned by
testEqualIntervalsInOneRecordSurviveOnlyWhenTheRecordIsOneInsert.

Tests

Package-level (runs in swift-packages.yml / ./gradlew testFullDebugUnitTest, no strap, no app):

• OuraStreamMappingTests / OuraStreamMappingTest — a record's beats become one batch;
  distinct seconds stay separate and in arrival order; interleaved same-second events fold into one
  batch with relative order preserved; empty input yields no batches. The Kotlin twin asserts the
  resulting ord end-to-end through StreamPersistence.toBatch + assignRrSeq: 0,1,2,3,4.
• MigrationTests.testV30OrdIsBatchLocalSoOneInsertPerBeatRecordsNoOrder — pins both shapes side
  by side: one insert per beat can only ever write ord = 0 and reads back in magnitude order; the
  same beats in one insert keep emission order. Kotlin twin: onePersistPerBeatRecordsNoOrder.
• MigrationTests.testEqualIntervalsInOneRecordSurviveOnlyWhenTheRecordIsOneInsert — the seq
  recovery above.

Verification

• swift test in Packages/WhoopStore: 354 pass, 0 failures.
• ./gradlew compileFullDebugKotlin clean; ./gradlew testFullDebugUnitTest: 3,473 tests, the
  same 3 pre-existing locale failures as clean main (AiCoachContextTest,
  StandardHrSensorFormatTest ×2) — verified by re-running them on a stashed tree.
• ⚠️ App-target Swift, which no default CI builds (app-build.yml is disabled). Built locally:
  xcodebuild Strand (macOS) and NOOPiOS (iOS Simulator) — both BUILD SUCCEEDED.
  StrandTests shows the same 73 pre-existing locale failures as clean main (1010 tests), none
  new.
• ⚠️ NOT yet validated on hardware. This is on the BLE/offload path, so compile success proves
  nothing. A post-fix drain still has to show: ord running 0,1,2,… within a second in
  rrInterval, and the resume cursor still reaching bytes_left 0 across a full offload.

What this does not fix

It does not by itself make Oura SDNN physiological. The validation night for #1071 showed a third
duplicated channel (0x60/0x44) dominating the scoring read, and beats banked in bursts rather than at
their true times. ord is the prerequisite for deciding channel selection on beat-accurate data
rather than on burst counts — it is not the decision.