Strain: weight each HR sample by its own gap, not the window's first one

[ryanbr]

A real defect found while investigating #950. The resting-HR fix that #950 actually confirms is
#972 — split out so each half carries its own evidence.

Read this first: the reporter's export shows his strap banking at 0.997 records/second, essentially
uniform. So the first-gap guess was probably right for his ride, and this fix likely is not what cost
him the 17. It is a genuine bug on non-uniform windows — where it can both under- and over-count, badly —
but its impact on real users is unquantified, and I would rather say so than let the #950 framing
carry it.

The bug

TRIMP guessed ONE per-sample duration from the window's first two timestamps and multiplied the whole
zone-weight sum by it. NOOP's HR stream isn't uniformly spaced — live Bluetooth ~1 s, banked 5/MG history
~30 s, dropouts larger — so whichever gap came first set the scale for the entire window. The workout
window and the day containing it start at different samples, picked different factors, and produced
Effort numbers that can't be compared. That's the report: a hard ride at 6.9 inside a day at 14.

The fix

Each reading carries the gap to its successor, clamped to 2 min so a dropout hole is never credited
to the reading before it (one zone-5 sample could otherwise invent hours of effort; unclamped, a 3 h gap
pair scores 1440 TRIMP — clamped, 16). The clamp is 4× the sparsest real cadence (~30 s, the #482 5/MG
path), so nothing genuine is truncated.

For uniformly spaced samples every gap equals the first gap, so results are identical to the old code
after the 2 dp strain rounding. Stated precisely after re-review: the raw TRIMP can differ at the ULP
level, because the old code multiplied the summed weights once while the new one rounds per term —
(Σw)·d vs Σ(w·d) differ in the 13th decimal on a 1 Hz cadence. It cannot survive trimpToStrain's
2 dp rounding, and CI proves it: every pre-existing strain assertion on both platforms passed unchanged.
Cross-platform Swift↔Kotlin parity is exact — both now accumulate in the same order.

The design has in-tree precedent I only found re-reviewing: estimateBoutCalories already weights
each sample by its own gap, clamped (min(gap, mergeGapS)). Calories were never wrong — only strain used
the single-factor shortcut. The clamps differ (150 s there, 120 s here — this one chosen as 4× the
sparsest real cadence); unifying them is possible but each is documented on its own reasoning.

Modelled old-vs-new before writing it:

shape	old	new
uniform 30 s hour, zone 4	61.75	61.75 (identical)
10 live 1 s samples + the same hour	25.54	61.94
two samples 3 h apart	8.9	capped at 16 TRIMP

What the clamp costs on a gappy day (re-review, quantified)

The framing above is mixed cadence, but the change has a second consequence I had not measured: wear
gaps. Old code effectively ignored them — every sample carried the first gap regardless — while each
sample before a hole now carries up to maxSampleGapMin. So a gappy day gains a little Effort.

Modelled on a 8 h day at 1 Hz, zone 1, with 20-minute gaps, against the reporter's own resting HR of 50:

wear gaps	old Effort	new Effort	change on the 0–21 scale
0	69.53	69.53	0.000
5	69.53	69.76	+0.048
20	69.53	70.42	+0.187
40	69.53	71.25	+0.361

The ceiling is 2 min × zone weight per gap, and the log map compresses it hard, so even a pathological
40-gap day moves about a third of a point on the scale users see. Worth knowing it is non-zero and always
upward; not worth tuning the clamp for.

Scope

Both platforms in lockstep, twin test files with the same fixtures: uniform-is-identical, the reported
mixed-cadence shape, day ≥ its own workout, the clamp, 30 s cadence not clamped, and the old edge-case
fallbacks. No strings, no schema, no BLE.

The second #950 defect is now here too

ManualWorkoutRescore scored every workout against a hardcoded resting HR of 60 — strain's %HRR
denominator and the calories model's active threshold both took the default — while the day total used
the wearer's measured resting. scored() gains restingHR (null = old behaviour, byte for byte), and
the engine threads the most recent scored day's measured rhr into the rescore, derived identically on
both platforms from the Computed days it just built.

Still default-60, deliberately: the display-fill (fillWorkoutHrFromStrap / Repository's
strainProfile fill) and the live-session paths. They are transient renderings, and threading a resting
source through app-target code on both platforms is a follow-up, not a rider.

Two of my test premises were wrong and CI caught both — worth recording since each was a test that
would have passed vacuously or asserted a mechanism that doesn't exist:

• the first strain fixture (145 bpm) sat in Edwards zone 2 under BOTH restings; the zone only flips in
  the 147–151 band, so it now uses 148;
• the kcal assertion assumed resting reaches the burn rate; it only sets the active threshold
  (resting + 30% HRR), so an all-hard window produces IDENTICAL kcal — both platforms failed with the
  same number, and the fixture now straddles the two thresholds (95 bpm warm-up).

Effect on stored data: scores recompute on the next analysis pass; historical Effort on
mixed-cadence days will change (upward). That is the fix working, but it is user-visible.