fix(workouts): one HR device-id rule for the chart, zones and Avg HR

[ryanbr]

Closes #856.

Four surfaces on one card, no two agreeing

surface	before	wrong when
Swift Avg HR	workoutHrDeviceId (single)	under-reads imported after a strap re-add
Swift chart	day union	reads the wrong strap for a bout detected on a second WHOOP
Swift zones	day union	same
Swift HRR	day union	same
Kotlin chart	single active id	both failure modes
Kotlin zones	single active id	both
Kotlin HRR	day union	wrong strap for detected

So on iOS the Avg HR and the HR curve on the same card could describe different straps. That is not a Kotlin-vs-Swift divergence — it is a live self-inconsistency.

Neither existing rule is right on its own

The correct read is source-class-dependent, which workoutHrDeviceId already encoded. It just returned one id where one case needs two:

detected          -> [recording strap]   a union mixes in a strap that never recorded it (#510)
manual / imported -> active ∪ canonical  no strap of its own; the worn strap may bank
                                         under either after a re-add (#814)

workoutHrDeviceIds returns that list on both platforms, and all four surfaces consume it:

surface	Swift	Kotlin
HR chart	✓	✓
zone minutes	✓	✓
Avg HR / Effort	✓	✓
heart-rate recovery	✓	✓

HRR's window extends past the bout, which is the one reason it might have wanted different treatment. It doesn't — the strap that recorded the session is still on the wrist a few minutes later.

The aggregate needed real work

A naive deviceId IN (…) double-counts a second banked under both ids — inflating n, skewing avg, silently, because both numbers stay plausible. GROUP BY ts with MIN(pri) keeps one row per second and takes the primary's, matching the dedup the chart already did.

Fixed 2-arity, not a bound collection: importedReadIds is 1 or 2 by construction, and Room @Query is static SQL that cannot express per-id priority through an IN list.

Passing the same id twice is byte-identical to the old single-id read, so a single-WHOOP install is unchanged and needs no special case. That is the control test, and it is what makes this invisible to almost everyone.

The aggregate lives in WhoopStore, where swift-packages.yml actually runs its tests — the placement that made #841's Swift half verifiable and its Kotlin half not.

Verification

Checked against SQLite before commit, and the Kotlin @Query was extracted from source and executed to confirm it returns the same numbers as the Swift twin:

A(0..9) + B(5..19), A primary  -> n=20  avg=150.0  max=200    (naive IN would say 25)
B primary                      -> n=20  avg=175.0             (precedence follows argument order)
PPG anti-join per id           -> n=15  max=130               (#841's anti-join still holds)
same id twice                  -> identical to the pre-change read

Tests: four added in WhoopStoreTests (overlap, precedence, per-id PPG anti-join, single-id control); five existing moved to the two-id signature with assertions untouched; both resolver tests (Swift + Kotlin) moved to the list API, plus two new Swift cases covering the behaviour the rename exists for — an imported row getting the full union on a multi-namespace install, and a detected row still resolving to one id on that same install.

Notes

• workoutHrBuckets, workoutZoneMinutes and workoutHeartRateRecovery take the row's source, defaulted so any caller without a row keeps today's behaviour.
• Swift's WorkoutRow carries no deviceId, so its resolver takes only source where Kotlin's also takes rowDeviceId — pre-existing and documented in the original missing Effort Score and no HR+Calories for Workouts #510 note.
• The day-level hrSamplesUnion / hrBucketsUnion are untouched and still used by Today, the full-day chart and the auto-workout nudge, where the union is the correct read.
• The Kotlin half is not compiled or run by CI. Its SQL was executed directly and matches the Swift twin's output.

[ryanbr]

Re-reviewed this against what I actually promised on #856 — "the chart, the ZONE MINUTES and hrWindowStats all read that list" — and had only done two of the three.

Zone minutes was missed, and leaving it would have been worse than not touching the screen at all. Chart and Avg HR would read the recording strap while the zone split still binned someone else's samples:

Swift zones    hrSamples(from:to:)   the day union  -> wrong strap for a detected bout
Kotlin zones   single active id      wrong for detected AND imported

That is a new three-way inconsistency on the card this PR exists to make consistent.

Both now resolve the same ids, via the sample-level twin of the bucket helper — Repository.hrSamples(deviceIds:) and WhoopRepository.hrSamplesFor, deduped by ts with earlier ids winning, so the zone split bins exactly the rows the curve plots. workoutZoneMinutes takes the row's source on both platforms, defaulted so any caller without a row keeps today's behaviour.

All three surfaces now go through workoutHrDeviceIds:

surface	Swift	Kotlin
HR chart	✓	✓
zone minutes	✓	✓
Avg HR / Effort	✓	✓

10/10 green, +271/-55.

Worth recording how this was caught: not by re-reading the diff, but by re-reading the issue comment listing what the fix should contain and checking each item off against the code. The diff looked complete on its own terms.