HRV window switch: re-fold the baseline from re-scored history instead of restarting calibration #201

Follow-up idea from #195 (not the reporter's own issue — theirs is genuine cold-start calibration).

Current behaviour

When a user flips the HRV window (Whole-night ↔ Deep-sleep) in Settings, the handler
(SettingsScreen Android / the Swift twin) does:

• UnitPrefs.setHrvWindow(...)
• re-anchor the HRV baseline to now (hrvBaselineEpochKey = now)
• clear the analyze watermark + force a re-score (vm.syncNow())

Re-anchoring to now restarts the ≥4-night HRV calibration — so a user with plenty of history who
switches the window drops back to "calibrating" for several nights, and Charge goes nilScore
(hrvStatus=calibrating hrvNValid<4). That reads as "the setting is broken" (see #195).

Proposed improvement

The same handler already forces a re-score, and analyzeRecent recomputes the recent ~21 nights'
avgHrv with the new window, deterministically from stored R-R. So instead of resetting the
baseline to zero, re-fold the HRV baseline from those just-re-scored nights in the same pass. Then a
window switch takes effect immediately for anyone who already has ≥4 valid nights — no artificial
calibration reset — while still being correct (the baseline reflects new-window values, because the
nights it folds were re-scored under the new window).

Caveats

• Both platforms, byte-parity — Swift IntelligenceEngine/baseline path + the Kotlin twins.
• Needs on-device validation across several nights (HRV baseline behaviour can't be CI-tested).
• Won't help a genuine cold-start user (few valid nights) — that's expected.
• Do this AFTER the per-night [hrv] always-on debug line lands, so the change can be validated
  against the new logging (instrument first, then tune).

Not urgent — the current behaviour is correct, just less responsive than it could be.