[SCENARIO] Morning Readiness Loop

[shchukins]

Problem

The user needs a trustworthy morning answer after sleep and recovery data are available. A fixed-time briefing can be stale if HealthKit has not synced, so the product must make freshness explicit and trigger the morning answer from fresh recovery data when possible.

User-facing flow

1. HealthKit sync completes from iOS.
2. Backend ingests, normalizes, and recomputes recovery, load state, and readiness.
3. Backend classifies data freshness as fresh, stale, missing, or partial.
4. The first fresh readiness state for the day triggers the morning briefing.
5. If no fresh sync arrives by fallback time, the user receives a clearly degraded/stale briefing instead of a false sense of certainty.
6. Today screen and Telegram show the same readiness state and freshness context.

Definition of done

• Morning briefing is triggered by fresh HealthKit processing, with schedule as fallback only.
• Duplicate daily briefings are prevented.
• Briefing and Today screen expose freshness state clearly.
• Stale data is never presented as fully reliable.
• iOS onboarding and system status make sync state understandable.
• Tests cover fresh, stale, missing, fallback, and duplicate-trigger behavior.

Linked existing issues

• iOS app as HealthKit ingestion layer #7
• [Feature] iOS onboarding flow #51
• [Feature] System status & sync screen #52
• [Feature] Event-driven morning briefing after HealthKit sync #88

Migration note

Created from the accepted end-to-end epic proposal in docs/product/END_TO_END_EPICS_PROPOSAL.md. This scenario epic is additive and does not close or rename existing issues.