Readiness score: Today card and Settings (2/5)

[ak710]

Second readiness PR (#103), building on the scoring engine in #104. This is the follow-up listed there as "2. Today tile + Settings".

Stacked on #104. This branch sits directly on top of feat/readiness-score, so until #104 merges the diff here shows both commits. Once it lands, this collapses to the single tile commit. Reviewing 3f1d618 alone is the intended unit.

Puts the score on screen as a full-width card pinned directly under the Today hero, above the metric grid, with its own Settings page.

Deliberately not a tile in the reorderable grid

Every other tile reports one measurement. Readiness is a verdict over those measurements — HRV, resting HR, sleep, temperature and yesterday's load collapsed into a single number. Placing it beside a peer tile framed it as a sibling metric, which is the wrong mental model, and half a tile's width couldn't carry the reasoning that stops it being a black box.

So it carries no MetricKey at all: it's pinned by design, and visibility is the Settings toggle's job rather than the drag tray's.

The width earns its keep. The card shows the score, its band, the share of signals it's based on, and the top two contributors holding it back — each with its own explanation and what it cost, e.g. "Skin temperature 0.5 °C above your baseline, −3.4 pts".

The empty state counts down instead of repeating an instruction

Readiness can't say anything until it knows what your normal looks like. A flat "wear your ring overnight" gives no sense of whether that means one more night or two more weeks — and on a device with a month of history it reads as broken.

The card now shows a filling ring with "3 of 7 nights" and "4 more nights to go", so the feature visibly works before it can produce a score.

Three things make that honest rather than decorative:

• Progress counts nights that actually produced overnight signal, not days since install. Someone who wore the ring twice in a month is two nights along, and saying otherwise would promise a score that isn't coming.
• A night whose sleep decode failed still counts if vitals were captured.
• Nights are a proxy for BaselineStats.isEstablished, which also requires enough individual readings — so the copy never claims "0 more nights" while still showing no score. It says it's still gathering readings instead. A test pins the advertised night count against the gate itself, so the countdown can't drift from what actually unblocks a score.

This also fixes a real gap in the previous copy: it keyed off the pairing calibration state, so a long-established user who simply lacked a readiness baseline saw a bare "No score yet" with no path forward.

Gating

The card is gated on its master toggle plus "can this ring measure recovery at all" — HRV or sleep, the two signals ReadinessScore requires. A ring with neither could never produce a score, so the card is absent rather than permanently empty.

Two things worth a closer look in review

1. Band zones live in ReadinessZones, not on a view. The card, the detail hero and the trend chart all need them, and none should depend on another's type name. A test pins them against ReadinessScore.band.

2. TodayStore needed two changes. ReadinessService.refreshIfStale runs before the signature is captured, not after — otherwise the write lands after the snapshot and forces a second, wasted rebuild. And the signature gained a readiness clause; without it a freshly scored night sits in the database while the card keeps showing yesterday's.

Progress is computed only while there is no score, so it never runs on the happy path.

Testing

25 new tests. Layout verified in the simulator against seeded demo data (-seedDemo YES), which #104 made produce 10 scored days across multiple bands.

Also adds an -openReadinessSettings launch arg, matching the existing nutrition test tooling.

Follow-ups

3. Detail screen with contributor breakdown and trend
4. Coach tool get_readiness
5. Widget metric
6. Check-in mention + sharp-drop anomaly rule

Each is already implemented on its own branch and will be opened as its parent merges, so no PR ever carries more than one step's diff.