Centralize quota freshness classification

[TheKrush]

Summary

Centralize quota-window freshness and health classification so dashboard, status-bar, tooltip, cache, and snapshot paths cannot drift into different interpretations of the same data.

PromptFuel 1.0.13 aligned the current behavior, but freshness is still evaluated in more than one layer. A shared classifier would make later quota changes safer and easier to test.

Current behavior

Quota freshness is derived in separate code paths for dashboard health and compact display/status behavior. Those paths currently agree on the important rules, including per-window timestamp ownership, conservative handling of timestamp-less values, and separate snapshot thresholds, but they can drift as new providers and quota surfaces are added.

Desired behavior

Use one canonical freshness classifier for quota windows, with callers supplying the value, trustworthy timestamp evidence, source kind, and applicable threshold. Dashboard, status, tooltip, cache restoration, and snapshot projection should consume the same effective result instead of reimplementing policy.

Requirements

• Define a shared result that can represent healthy, missing, and stale states with an optional truthful age/detail.
• Keep normal provider freshness scoped to each window's trustworthy timestamp.
• Keep imported snapshot freshness tied to the snapshot generation timestamp.
• Preserve the existing 20-minute normal-window threshold and two-hour imported-snapshot threshold.
• Preserve the rule that a numeric value without trustworthy timestamp evidence is stale.
• Preserve the rule that a wholly unavailable value is missing.
• Keep five-hour and seven-day windows independent.
• Prevent provider-wide refresh times, file access times, cache-read times, or sibling timestamps from manufacturing freshness.
• Make dashboard, tooltip, status-bar, cache, and snapshot callers use the shared classifier where applicable.

Non-goals / constraints

• Do not redesign the quota data model or implement a general UsagePool abstraction in this issue.
• Do not change the user-facing 1.0.13 behavior unless a verified inconsistency is found.
• Do not reintroduce synthetic percentages, warning decorations, or provenance labels.
• Do not expose authentication data or raw provider payloads in diagnostics or tests.

Acceptance criteria

• One canonical classifier owns effective missing/stale/healthy decisions.
• Existing dashboard, status-bar, tooltip, cache, and snapshot behavior remains consistent.
• Fresh per-window evidence overrides obsolete carried stale state.
• Old or missing per-window evidence remains unhealthy regardless of provider-wide state.
• Exact 20-minute and two-hour boundary behavior remains covered.
• Current and legacy cache restoration remain covered.
• No duplicated production freshness policy remains in renderer-only code.
• The complete validation and packaging workflow passes.

Validation

• Add focused unit tests for the shared classifier and each caller integration.
• Preserve regression coverage for partial Codex windows, cache restart, imported snapshots, provider tabs, status bar, tooltip, and dashboard Quota issues.
• Run the repository's canonical compile, unit, smoke, manifest, encoding, package, and local-install workflow.