fix(sleep): hand the #899 heal's bank-recency witness to the computed id only, never to a ring's own rows

[pipiche38]

What the user saw

An Oura night (iOS 11.8.0, 2026-09-19 → 20) displayed as ending 04:48 when the wearer woke at ~08:18. The ring had served the full night — the strap log shows sleep session persisted [22:23:51 → 08:21:51] at 08:37:22 — and the #899 heal deleted it one second later:

Dedup(#1284): dropped [1789874631 -> 1789910511] min=598 … kept [1789874453 -> 1789894673] min=337 … - heal

The same heal had already dropped the 388 / 471 / 514-min re-serves earlier that morning, each time keeping the 337-min row (22:20 → 03:57). The day then scored on that row plus a 26-min no-onset fragment (04:22 → 04:48): sleep day=2026-09-20 totalSleepMin=315, night ending 04:48.

Root cause

The post-upsert heal runs SleepSessionDedup.dedupe(healable, freshStarts: keptStarts) for every id in healDeviceIds (#1248), including the ring's own. keptStarts is the computed pass's bank-recency witness, and the comment claimed it "only matches the computedId rows". That is false on an Oura day: the pass's sessions are the ring's providedSleep rows with startTs copied verbatim (analyzeDay folds provided sessions unchanged), so the same key names the row the pass read in the ring's own table. In the ring's sweep that row ranks "fresh" (rank 2 in rankKey) and beats "longest" (rank 3) — the heal prefers whatever the pass consumed at read time over anything the ring persisted afterwards.

It bites hard on a phone because the OS suspends the app between a pass's read and its heal (04:14 read → 07:22 heal here), and the app wakes precisely for the BLE drain that banks the fuller re-serve. It is self-perpetuating: the next pass reads only the survivor, re-witnesses it, and deletes the next fuller row.

Not a regression from a recent build — #1248 landed 2026-08-11; long/suspended passes just widened the window.

Fix

One shared rule, SleepSessionDedup.healWitness(for:computedId:keptStarts:) (Kotlin twin healWitness(healId, computedId, keptStarts)): the witness is handed to the computedId sweep only; every other id gets none and falls back to longest-wins, the read-side default — which the #1284 corpus already showed is the WHOOP-matching row on every night. The heal's existing re-arm re-pass then scores the kept full night. No schema change, no behaviour change for a WHOOP strap (its rows live only under computedId).

Verification

• Packages/WhoopStore: swift test --filter SleepSessionDedupTests — 33/33, two new: the witness rule, and the 09-19/20 scenario (read row 337 min in keptStarts, fuller 598-min re-serve) keeps the fuller row through the ring's sweep; the leaked-witness outcome is pinned in the same test so the regression cannot creep back.
• Android: ./gradlew testFullDebugUnitTest --tests com.noop.analytics.SleepSessionDedupTest — 33/33, same two tests case-for-case; compileFullDebugKotlin green.
• macOS app target compiled locally (xcodebuild … -scheme Strand … build), since swift-packages.yml does not cover Strand/Data/IntelligenceEngine.swift.
• Hardware: not yet — needs one night on a ring with the pass suspended across a drain. The strap-log proof is the Dedup(#1284): dropped … kept … line reading dropped min=<shorter> kept min=<longer> after a wake, which the 09-19/20 export shows inverted.

Refs #899, #1248, #1284.

[pipiche38]

The heal did exactly what #2372 intended

Three heals fired in your capture, and every one of them drops the shorter row and keeps the fuller:

Dedup(#1284): dropped [1790048761 -> 1790060641] min=198 segs=20 kept [1790048801 -> 1790072201] min=390 segs=52 - heal
Dedup(#1284): dropped [1790048714 -> 1790074934] min=437 segs=52 kept [1790048694 -> 1790079834] min=519 segs=57 - heal
Dedup(#1284): dropped [1790048801 -> 1790072201] min=390 segs=52 kept [1790048694 -> 1790079834] min=519 segs=57 - heal

That is the inverse of the 9/20 report, where the line read dropped min=598 kept min=337 — the
fuller row was the one being deleted. The 519-minute row survives to the end of the capture: the three
Dedup(#899) sweeps that follow all report removed 0, so nothing re-took it.

Worth saying explicitly for anyone reading later: we could not produce this shape on our own
hardware. Our 09-21/22 night was fully 0x49-anchored, every persist keyed the same generation, and
the heal reported removed 0 on all four passes — so the fix went in with the defect never having
been observed against it. Your night is the first evidence that the corrected witness behaves the way
the change argued it would.

The SpO2 line — you found a real bug, but not the one it looks like

Short version: SpO2 was working the whole time. Two separate things are confusing the log.

1. subscription=0 is not the off switch. Counter-intuitive, and we should probably say so in the
line itself. The ring reports subscription=0 for features that are plainly running — daytime HR
streams at subscription=0 — so the code deliberately does not treat it as a gate. What the code
reads as "the cloud never enabled this" is mode, status and state all zero, and it prints an
explicit - INACTIVE (server-gated off; …) suffix when that happens. Your lines read
mode=1 (automatic) with no such suffix, so nothing in that line claimed SpO2 was off.

On our own ring, where SpO2 is unambiguously working (Oura app 96 %, NOOP's Blood Oxygen card 96 % the
same morning), every feature-status line all night also reads subscription=0.

2. dc_raw is a different channel from the SpO2 percentage. The ring sends two things:

• 0x6F — the firmware-computed SpO2 percentage, tagged raw (a legacy channel label)
• 0x77 — a raw DC perfusion channel, tagged dc_raw, whose magnitudes run from about
  −1,000 to 11.7 million

first SpO2 decoded (last night) fires on whichever .spo2 event the drain happens to serve first,
and prints its value and unit without distinguishing the two. In your capture the first one was a
0x77, hence value 41132 (dc_raw) — a perfusion count, not a percentage, and not evidence of
anything being off.

Both channels were flowing in your bundle. Walking the raw sidecar gives 5,089 0x6F packets (the
percentage channel) against 12,646 0x77 — so the percentage channel was live the whole night.
Your 360,847 stored spo2 rows are consistent with that.

You can see the coin-flip directly on our side. Same line, same ring, consecutive reconnects:

[23:50:43] Oura: first SpO2 decoded (last night) - value 93 (raw)        <- 0x6F, a percentage
[02:32:27] Oura: first SpO2 decoded (last night) - value -288 (dc_raw)   <- 0x77, perfusion
[02:39:56] Oura: first SpO2 decoded (last night) - value 101144 (dc_raw)
[06:53:30] Oura: first SpO2 decoded (last night) - value 93 (raw)

Nothing changed about the ring between 23:50 and 02:32; only which packet arrived first.

So there is a defect here, and it is the log line. Calling a five-digit perfusion count "SpO2" is
exactly the kind of diagnostic that asserts more than it observed, and it cost you a false alarm.
It should name the channel — and arguably report the percentage channel and the raw channel
separately, since one of them is the number a reader actually wants. Happy to open that as a small
PR if it is wanted; it is a log-copy change, no behaviour.

(Unrelated but worth knowing while you are looking at SpO2: roughly 47 % of decoded 0x6F samples
read above 100 %, which no ground truth yet explains. Those land in the raw channel only and never
reach the Blood Oxygen card, so they do not surface as readings — it is a known open question in
docs/OURA_PROTOCOL.md §6.5, not something your test introduced.)