Validate + enable the band sleep_state wake-veto (flip #738 default-on) #1210

Follow-up to #738, which landed the band sleep_state wake-veto as default-off dormant groundwork (bandStateWakeVetoEnabled = false, no call site overrides it → no-op in production). The mechanism, parity, and tests are in; this issue tracks validating it and flipping it on.

What the mechanism does (recap)

After staging, applyBandStateWakeVeto reclassifies an interior wake epoch to light only when WHOOP's own per-second band sleep_state (v18 @81 high-nibble, 2 == asleep) scored that epoch asleep. Conservative by construction: never moves sleep onset earlier or final wake later; only wake→light (efficiency/TST/light can rise, nothing moves down); deep/REM and the recovery gate are never written; no-op when the band is absent (WHOOP 4.0) or the flag is off. Byte-equivalent Swift (SleepStager.swift) / Kotlin (SleepStager.kt).

Before flipping default-on

1. Widen validation. The PR cited 12 banded nights (~30 min/night recovered vs ~2 min/night reverse error) — promising but thin. Confirm the recovered-vs-reverse-error ratio holds across more banded 5.0/MG nights and more wearers before trusting it as the default.
2. Decide the retroactive-rescore story. Default-on re-scores banded nights already in history with higher efficiency / TST / light (deep/REM/recovery untouched, so nothing drops). That's a visible, one-time shift — decide whether to just ship it, note it in the What's New, or gate it so only new nights get the correction.

The flip (when ready)

• Set bandStateWakeVetoEnabled = true in both Packages/StrandAnalytics/.../SleepStager.swift and android/.../analytics/SleepStager.kt (keep them in lockstep — analytics parity).
• The unit tests already pass enabled: true, so they cover the on-path; add/confirm an e2e assertion that a banded night's efficiency rises as expected.
• One-line change per platform; the hard part (mechanism + parity + tests) is already merged.

cc @vishk23