Add reset primer for provider accounts

[cbusillo]

Objective

Add a reset primer for provider accounts so Context Panel can verify that a reset actually happened, refresh the baseline immediately, and update the widget without waiting for incidental user activity.

Finish Line

When a tracked account/window reaches its reset time, the app schedules a small, controlled post-reset refresh/primer for that account, records a fresh snapshot baseline, reloads the widget, and surfaces failures as actionable degraded state rather than stale normal data.

Current Status

State: Settings/model and shared planning/state slices are done. PR #50 added persisted reset-primer settings with global opt-in, delay-after-reset, account staggering, and per-account enablement exposed in Settings. PR #51 hardened duplicate account IDs. PR #52 added shared reset-primer planning/run state that computes due/upcoming reset-window candidates, persists one-shot completion/failure state, retries failed runs, redacts errors, and can be used by app or refresh agent without provider-specific traffic.
Next action: Design and implement provider-specific primer executors behind the shared plan service, starting with the safest validated provider method only.
Blocked by: Provider-specific cheapest action validation remains before execution should send anything.
Last verified: 2026-05-09: PR #52 CI/CodeQL passed; post-merge main CI/CodeQL passed.

Scope

• Detect reset crossings for account/window limits.
• Schedule a one-time post-reset primer with jitter/backoff so resets do not stampede.
• The primer is intentionally the cheapest possible real provider message/action that starts the new rolling window for that account. It is not just a usage refresh.
• Keep primer behavior opt-in per provider/account, but design it as a first-class wanted feature, not a discouraged fallback.
• Choose the lowest-cost, lowest-token, non-content-bearing prompt/request that reliably starts the provider window.
• Persist primer results in snapshot history so burn-rate math starts from the new reset baseline.
• Stagger multi-account primers so accounts do not drift into the same reset/pressure pattern unless explicitly requested.
• Trigger WidgetKit reload after successful primer or degraded-state update.

Acceptance Criteria

• OpenAI weekly and 5-hour reset windows can be primed per account after reset by sending the cheapest possible successful message.
• Claude reset windows can be primed per account using the cheapest possible successful message/action available for the configured account.
• Gemini daily reset can be primed per account using the cheapest possible successful message/action available for the configured account.
• Primer configuration is explicit and opt-in, with per-provider/account enablement and clear cost/rate-limit wording.
• Primer actions avoid collapsing multiple accounts into the same effective reset schedule; scheduling supports intentional staggering.
• Primer actions never hide failed refreshes behind normal-looking stale data.
• Tests cover reset-crossing detection, one-shot scheduling, cheapest-message request construction, backoff, snapshot baseline recording, account staggering, and widget reload request behavior.

Relationships

• Related to Keep widget data fresh when host app is closed #34 because a reset primer depends on having a background refresh path when the app is closed.
• Related to Build OpenAI weekly reset fast-mode forecast #9 for fast-mode/runway accuracy after reset.
• Related to Build local snapshot storage and history #16 for snapshot history baselines.

Validation

• Unit tests for reset-crossing detection and primer scheduling.
• Provider-adapter tests for non-secret, sanitized primer outcomes.
• Manual validation by forcing/fixtureing a reset boundary and confirming widget/app update without opening the main window.

Decisions

• "Primer" means sending a tiny real message/action to start the provider/account's new rolling window immediately after reset.
• This is wanted product behavior because otherwise the window may not start until first real use, which can make both accounts hit limits in the same week.
• Primer must be opt-in and configurable, but the implementation should treat it as a supported workflow.
• Use the cheapest possible provider action that reliably starts the relevant window; do not choose a heavier probe just because it is easier to implement.

Open Questions

• For each provider, what is the cheapest reliable message/action that starts the target window?
• Should primers run exactly at reset, a few minutes after reset, or at a configured offset to preserve account staggering?
• Should the widget indicate that an account was just primed, or should this stay invisible unless it fails?

[cbusillo]

Superseded by #75, which now carries both the original product intent from this issue and the later safety blockers discovered during live testing. Keeping #75 as the single reset-primer source of truth avoids duplicate planning before TestFlight.