[ryanbr]

@rodrigosa7's work from #2441, rebased onto current main with the conflicts worked through and the parity gate satisfied. Both of their commits are unchanged. This branch exists only because a push to their fork is refused (maintainer_can_modify reports true, the push does not), so the follow-up could not be added to their PR. Merging with rebase so all three commits keep their own author.

Raised in #2335, #1118, #2336.

Their change

WHOOP 4.0 type-47 historical R-R gets its own label (code 8), so it can be told apart from the overlapping unlabelled live BLE feed. HRV reads then select ONE stream for the whole window, history when the window has any, the unlabelled rows otherwise. Exact-key historical replays promote existing legacy rows, and the analysis fingerprints bump so cached nights rescore.

The diagnosis is right and it matches the shape #2423 settled on for Oura: when two sources cover the same beats, score one of them for the interval rather than splicing both and reading 1.0+ coverage. Here the pair read as crossSecondOverCount and the #1118 gate withheld a plausible whole-night RMSSD.

Checked rather than assumed: the family: DeviceFamily = .whoop4 default that labels unlabelled frames looks risky in isolation, but it mirrors the Kotlin twin, where that exact default has been on main at three signatures already, and both production call sites (Backfiller, RawHistoryArchive) pass it explicitly.

What the follow-up does

The rebase, which is the substantive part. The base predates #2423 and #2457 and both touch the one read this changes, so taking either side literally would have dropped one of them without saying so. rrIntervals is now a three-way choice: WHOOP 5 takes the lowest scorable transport, a WHOOP 4 takes its type-47 history (or its unlabelled rows when the window has none), and everything else takes the Oura branch, one channel per window. OuraRedrainCollapse.withoutRedrainedRuns still wraps the result on both platforms; the Kotlin conflict would have removed it from WhoopRepository too.

The parity gate. parity-governance.yml filters on Tools/parity_*, and the branch as SUBMITTED touched only Packages/** and android/**, so the gate would not have run on it and the findings below would have reached main ungoverned. It runs on this branch only because the follow-up commit touches Tools/parity_dispositions.json, which matches that filter. Found by running it locally, and each of the five findings got the remedy that fits it:

• extractHistoricalStreams took a declared twin reference, NOT a disposition. The Kotlin twin exists; adding family only moved the Swift identity, which the inventory keys on arity. A platform_specific rationale there would have been false, and permanent.
• the three Room DAO methods and their two @Query constants took platform_specific dispositions. Room needs a generated method and a compile-time constant string; the Swift store issues the same SQL inline in Reads.swift and StreamStore.swift, which is why the WHOOP 5 siblings are one-sided for the same reason. Hashes came from parity_ledger._canonical_sha256.

--migrate-authority was deliberately not used. It waives whether the BASE's stored manifest reproduces, so using it to absorb debt a branch introduces would be laundering.

Two small things: isWhoop4RRSource gained the doc its siblings have, including that confirmedRegistryFamily returns nil for an unknown registry and nil must not be read as "a WHOOP 4"; and the promote path names the enum case instead of force-unwrapping an optional its own pattern match already proved non-nil.

Verification

• swift test WhoopProtocol: 803 tests, 0 failures, 1 corpus-dependent skip
• swift build WhoopStore: clean, with the merged three-way predicate
• swift test WhoopStore: cannot link on Linux (sqlite3_snapshot_cmp), so its new selection tests are CI's to run
• Android: compile clean, 6462 tests, 2 failures
• parity_ratchet.py: errors=0 locally, and parity-governance is in this PR's own check roster
• parity_ledger.py: the three DAO findings remain listed as inventory drift and are dispositioned, which is what the ratchet checks

The two Android failures are DebugExportSchedulerTest.targetEarlierTodayRollsToTomorrow and targetEqualToNowRollsToTomorrow, which fail identically on untouched main. They are #2477, a DST-boundary bug in that test, and they clear by themselves after 2026-09-28.

One known trade, worth stating rather than discovering later

Promotion relabels NULL to code 8 only on exact key matches, while the read is all-or-nothing per window. A PARTIAL historical offload therefore promotes part of a night, and the read then drops the un-promoted unlabelled rows, lowering coverage, which is what the #1118 gate refuses on. So an interrupted offload could newly withhold an RMSSD that today's over-counted read produces.

Merged as-is on purpose. The alternative, preferring history and filling gaps from the live feed, re-introduces the overlap at the seam, which is the bug. The direction of failure here is a refusal to score rather than a wrong number, and a refusal is visible in the hrv diag coverage line.

Hardware proof is owed, as the description says: a whole-night RMSSD on a 4.0 whose window carries both a type-47 offload and live BLE, with hrv diag showing coverage at or below 1.0 rather than crossSecondOverCount.