Finish safe reset priming for supported providers

[cbusillo]

Context

Context Panel has reset-primer settings/planning/state plumbing, but automatic primer execution is intentionally disabled for now.

During local testing, a Code CLI primer-equivalent command returned ok, but reported high reasoning and used thousands of tokens even when low/minimal effort overrides were supplied. Code also supports multiple auth accounts in auth_accounts.json, while the CLI does not currently expose a safe, documented way to run a primer against one specific account without mutating active auth state.

Goal

Implement reset priming only when it is safe, cheap, and account-selectable.

Acceptance criteria

• Provider-specific priming strategy is explicit; unsupported providers are shown as unsupported instead of silently executing placeholder commands.
• OpenAI/Code priming can target each account deterministically, or remains disabled.
• Primer command/API uses the cheapest viable model/mode and verifies that the requested model/reasoning settings are honored.
• Background priming never silently spends a high-reasoning/high-cost turn.
• Failures are recorded in reset-primer-runs.json and surfaced in the app without blocking normal refresh.
• Sandbox/App Store constraints are validated from /Applications/Context Panel.app, not a DerivedData build.
• Tests cover supported, unsupported, missing-command, failed-command, and multi-account cases.

Notes

Current behavior is safe-by-default: planner/settings/state exist, but execution skips providers until a proven implementation exists.

[cbusillo]

2026-05-14 update from local testing:

• Keep reset priming deferred for TestFlight. The plumbing/settings/planner are useful, but execution should remain safe-by-default until provider-specific cheapest actions are proven.
• Code/OpenAI live primer-equivalent testing showed this is not safe to assume yet: low/minimal settings were not clearly honored and the command used a large number of tokens. Multi-account targeting from auth_accounts.json also still needs a deterministic account-selection story.
• Current blocker remains provider-specific proof for cheapest viable action, per-account targeting, and signed /Applications runtime validation.

Next action for this issue: design primer executors as explicit provider strategies and leave unsupported providers as unsupported/skipped in the product UI rather than silently executing placeholder commands.

[cbusillo]

2026-05-14 status update:

Reset primer remains deferred. The planner/executor scaffolding and tests exist, but provider-specific cheap/safe primer commands are not ready for beta.

To avoid a misleading or half-active feature:

• Settings now presents Reset Primer as planned for a later build and disables its controls.
• The refresh login item no longer calls ResetPrimerExecutor.runDue() in the background.

Rationale: the current executor has no provider-specific command arguments and correctly skips supported providers. Until #75 defines cheap, account-safe commands and expected behavior, reset priming should not appear enabled or silently run.

[cbusillo]

Consolidating reset-primer planning here and superseding #35.\n\nWhy this issue is the source of truth now:\n- #35 captured the original product idea: prime reset windows with tiny provider actions so baselines start promptly.\n- Real testing showed the core risk: a supposedly cheap Code primer path used high reasoning/thousands of tokens and did not prove deterministic account selection across auth_accounts.json.\n- For TestFlight, safe-by-default matters more than shipping the clever behavior. The product currently keeps reset-primer UI disabled/planned for later, and background execution is not active.\n\nCarried-forward requirements from #35:\n- Primer behavior remains a wanted product capability, not abandoned.\n- Each provider needs an explicit strategy. Unsupported providers must show unsupported/skipped, not silently run placeholders.\n- OpenAI/Code, Claude, and Gemini each need the cheapest reliable action proven before enabling.\n- Multi-account targeting and staggering must be deterministic.\n- Primer results/failures should update run state/snapshot/widget without hiding degraded provider state.\n\nCurrent release decision:\n- Do not block the first trust-focused TestFlight beta on reset priming.\n- Do not enable background primer execution until cheapest, account-safe provider strategies are proven from the canonical /Applications runtime.