Oura: stamp banked IBIs at their real ring-time, not the drain-arrival time

[pipiche38]

Summary

A banked Oura IBI (a 0x60/0x80/0x6E history record) is enqueued with ts: now — the wall-clock moment the history drain arrived — instead of its real ring-time, unlike every sibling banked
stream (.hrv/.temp/.spo2/.sleepPhase, which anchor via unixSeconds(forRingTimestamp:)). The anchor was wired for those streams when it landed (52b6e88d) but .ibi was left on now.

The effect

A night's history is drained the next day, so every overnight beat is written to rrInterval at the daytime sync moment: the deep-night hours (00–06 local) come out empty while the sync hour
piles up an implausible density of beats. Any consumer of the Oura R‑R series (HR charts, HRV / daytime-stress analytics) reads the wrong time axis. The oura-ibihr diagnostic corpus was always
correct (it uses the anchored ring-time), so the data is fine — only the datastore timestamp was wrong.

Fix

Anchor .ibi exactly like the sibling banked streams, with the hold-until-anchor pendingAnchorEvents fallback for a beat that arrives before the session's UTC anchor lands. Swift + Android twin
(OuraLiveSource.swift / OuraLiveSource.kt).

• Live HR is untouched — that's the .hr live push.
• The live R‑R strip (setRRIntervals / liveSink) is unchanged — only the persist timestamp moves to real time.

Scope note

main has no Oura sleep-session persist yet, so the visible payoff here is a correctly time-stamped rrInterval. The downstream benefit — a persisted Oura sleep session carrying
restingHr/avgHrv — lands once that path merges; this fix is the correct prerequisite either way.

Cross-platform

Both platforms, same change; the bug and the sibling-stream anchor both exist on each. No stored-data shape change — only the timestamp of an already-persisted row — so no migration.

Verification

• xcodebuild … -scheme Strand -destination 'platform=macOS' — BUILD SUCCEEDED.
• Android ./gradlew compileFullDebugKotlin — OK.
• BLE dispatch isn't unit-testable (the anchor primitive unixSeconds(forRingTimestamp:) it reuses already is). Hardware validation, next drain: overnight rrInterval populates at real times and
  matches the oura-ibihr corpus (00–06 local no longer empty).

[ryanbr]

Thanks for this — the core fix is correct and worth landing. .ibi really was the one banked stream still stamped at now instead of anchored via unixSeconds(forRingTimestamp:), so a night drained the next day wrote every beat to the daytime sync moment (deep-night rrInterval empty, sync hour impossibly dense). Anchoring it like the siblings is right; I confirmed a live IBI still anchors to ~now, the live R-R strip is untouched, and the park/flush fallback handles the pre-anchor beat. The Kotlin side is good as-is.

One request before merge, on the Swift side only.

The noteStoredHistoryRingTime(ibi.ringTimestamp) line can skip banked history

The Swift .ibi case adds noteStoredHistoryRingTime(ibi.ringTimestamp), which feeds the IBI ring-time into the history resume cursor (drain.maxStoredRingTime, committed by commitResumeCursor). The sibling streams do this safely because they are history-only — their ring-times always fall inside the drained sleep window. IBI is the only stream that arrives both live and banked, and the two are indistinguishable at that call site except by ring-time.

Failure path:

1. A large backlog drain force-stops early — the 300 s deadline or the stall guard fires with bytes_left > 0, so an un-drained banked remainder is still pending. (Those guards exist precisely for big backlogs.)
2. A live IBI push interleaves during that drain (ring-time ~now, resolves under the anchor) → maxStoredRingTime jumps to ~now.
3. commitResumeCursor(drainCompleted: false) commits maxStoredRingTime anyway → the cursor leaps to ~now.
4. The next fetch seeks from ~now and skips the un-drained middle backlog — permanently, never re-fetched.

The pre-fix code didn't have this, because .ibi never touched the cursor: a force-stop resumed from the last banked sample. The new line introduces it.

Suggested change

Drop just that one line — keep the anchoring:

case .ibi(let ibi):
    if feedsLive { live.setRRIntervals([ibi.ibiMs]) }
    if let ts = driver.unixSeconds(forRingTimestamp: ibi.ringTimestamp) {
        enqueue([e], ts: ts)
        // NOTE: unlike the history-only siblings, do NOT noteStoredHistoryRingTime here —
        // IBI also arrives live (ring-time ~now), and letting a live beat advance the resume
        // cursor can skip an un-drained banked remainder on a force-stopped drain.
    } else {
        pendingAnchorEvents.append((e, ibi.ringTimestamp))
    }

This costs nothing: the resume cursor is still driven correctly by the history-only sleep streams (hrv/temp/spo2/sleepphase) that share the same night window, and it makes the Swift path match Kotlin, which never notes any stream's ring-time (so the Kotlin side of this PR is already safe). The safe failure direction — re-drain + dedup — is exactly what Kotlin already does.

Minor

The ingest doc comment (both platforms) still lists IBI under "Live-push events … stamped at wall-clock arrival time" — after this change IBI is anchored, so that line is now stale. A one-line update would keep it honest.

Happy to push this myself if you'd rather — just say the word.

[pipiche38]

Done in 71d391d. Dropped the cursor note in .ibi (kept the anchoring) — and while there, closed the same hole in the park/flush path: a parked live IBI (arrived before the anchor) would've advanced the cursor at flush for the identical reason, so drainPendingAnchorEvents now skips the note for .ibi too. Reworded the stale wall-clock doc comment on both platforms. Kotlin cursor logic untouched (already safe). Built: macOS Strand BUILD SUCCEEDED, Android compileFullDebugKotlin clean.

[pipiche38]

Kindly merge with the order is still #677 → #678