[ryanbr]

Addresses #1988. Supersedes #1989, which gated only the Android driver row; see below for why that was the wrong shape.

The defect

Baselines.foldHistory returns the config's synthetic midpoint (about 75 bpm for resting HR) when the history is empty or entirely out of physiological range. Every engine passed that straight through, so the headline Charge on both platforms was z-scored against a baseline the user has never had. This is the same defect #1982 addressed for WatchRecovery, in the path that reaches the ring.

Where the gate goes, and why three places

Not at the eight call sites, but at the three places that read this baseline:

1. RecoveryScorer.recovery's BaselineState overload. AnalyticsEngine and IntelligenceEngine reach it on both platforms. This mirrors how hrvBaselineUsable is already derived one line below, so the two baselines are now handled the same way.

2. chargeDrivers. This one is easy to miss and it is why the first attempt was wrong: chargeDrivers builds the row from the baseline directly, its z, its mean and its verdict, not only through the scorer. Gating the scorer alone would have emitted an RHR row scored against the midpoint while the headline excluded it, which is worse than the original defect and would falsify the contract chargeDrivers documents, that its rows are scored "against the identical inputs as the headline number".

3. RecoveryScorerTrace. Found on a re-review, and the same shape a third time: the trace builds its own charge baseline rhr line, its rhrZ and the saturation guard from the baseline directly. Ungated, it would have named an rhr term the score did not use, which is the one thing a trace must never do, and which its own comment promises cannot happen: "The score the dashboard reads, verbatim, so the trace cannot diverge from it."

Gating all three keeps that invariant true, which is the point. Gating any subset is worse than gating none: the score and the thing describing the score would disagree.

Why not #1989

#1989 gated only Android's TodayScoring, to match the iOS views. Re-reviewing it showed that would have made things worse in a specific way: Android currently satisfies the identical-inputs contract (drivers and headline both ungated, both wrong), and a view-only gate would have introduced the divergence on a platform that did not have one. iOS already has it, since its views gate while its engine does not. This PR removes the divergence on both platforms instead of spreading it.

User-visible effect, and it is real

For a user with fewer than four valid resting-HR nights, an all-implausible history, or a baseline stale beyond 14 nights, the RHR term now drops and Charge renormalises onto the remaining terms. The number moves, for existing users, on both platforms.

No stored value is rewritten, so history will hold a mix of old-rule and new-rule days, the same situation #1987 tracks for #1982. This needs a release note. Since usable is provisional-or-trusted, a real personal baseline that has gone stale is dropped as well, which is the reading of "usable" the rest of the codebase uses.

Tests

Eight mirrored per platform, 1:1 by name. Three are controls proving the gate is not a blanket off: a usable baseline still contributes to the score, still produces its row, and still produces its trace term and baseline line. One pins the invariant directly, that passing an unusable baseline is indistinguishable from passing none, row for row.

Verified non-vacuous rather than assumed: with the gates reverted, 4 of the 6 original tests go red and every control stays green. The pre-existing RecoveryScorerTraceTest passes unchanged at 10/10, so the trace's other invariants are intact.

Full Android suite: 668 classes, 5,648 tests, 0 failures. doc_comment_lint.py clean. Swift is CI-verified as always; I checked the Swift API assumptions by hand first, which caught that ChargeDriver.label is a String there while the Kotlin twin uses a ChargeDriverLabel enum.