Expose observation coverage for aggregated summaries

[slash-init]

Problem

Daily summaries are computed from the hourly summaries that exist. If Pulse or the aggregator is unavailable for part of a day, some hourly summaries may never be generated.
The current rollup correctly aggregates the available data, but it does not indicate that the underlying observations were incomplete. As a result, an operator may interpret a daily uptime percentage as representing the entire day when it actually represents only the observed portion.

Example

Suppose a service is monitored every 30 seconds.

• Expected checks in a day: 2,880
• Recorded checks: 2,100
• Uptime: 99.8%

The uptime percentage is mathematically correct for the 2,100 observed checks, but the operator has no indication that roughly 27% of the day's observations are missing.

Possible Approaches

Option 1: Compute coverage at read time

Derive the expected number of checks from the service interval and compute coverage dynamically.

expectedChecks = 24h / service.Interval
coverage = totalChecks / expectedChecks

Pros:

• No schema changes.
• Can be added by the API or dashboard.

Cons:

• Every consumer of summary data must remember to compute coverage independently.

Option 2: Persist coverage

Store an additional field (for example, expected_checks or coverage) in CheckSummary during aggregation.

Pros:

• Single authoritative value.
• Simpler consumers.

Cons:

• Requires a schema migration and changes throughout the storage and API layers.

Current Behavior

The current implementation is intentional and mathematically correct for the observations available. This issue tracks improving visibility into incomplete observation windows rather than fixing an incorrect aggregation algorithm.