Add a guarded provider circuit override command

[highbyte]

Problem

Wrighty maintains installation-local provider availability state so one exhausted or rate-limited provider does not cause every eligible work item to launch another failing agent process.

Normal recovery is already safe and evidence-based:

• wrighty provider probe AGENT performs an explicit capacity check and updates the circuit from the result; and
• wrighty worker --item <id> ... deliberately overrides automatic timer/circuit filtering for one selected item.

There is no provider-wide administrative operation for the narrower case where an operator independently knows that a readable circuit record is no longer valid and deliberately wants automatic selection to consider that provider available again without starting a probe request.

Deleting provider-availability-v1.json manually is too broad. It bypasses store locking, can erase unrelated providers, and can invalidate an active cross-process probe lease.

Desired command surface

Add a guarded provider-domain operation, provisionally:

wrighty provider clear-circuit AGENT [--yes] [--json]

The final verb may be refined to match the existing CLI grammar, but it must communicate that Wrighty is clearing its local circuit state—not resetting provider quota, changing billing, or proving that capacity is actually available.

This command operates on installation-local provider state and is relevant to workers using either the GitHub or Local Markdown backend. It should work from any directory without requiring a valid tracker configuration or contacting a tracker backend.

Required semantics

• Treat wrighty provider probe AGENT as the normal and recommended recovery path because it obtains current provider evidence.
• Require an explicit normalized agent name supported by the provider availability store.
• Acquire the same cross-process store lock used by provider circuit and probe operations.
• If the provider is unavailable-until, atomically mark it available, clear its unavailable-until value and consecutive-failure count, and record that the transition was an operator override rather than a successful probe.
• If the provider is already available or has no record, return an idempotent no-op result.
• Refuse to clear a probe-due record while its probe lease is unexpired. Report the lease expiry and explain that the running probe or lease expiry must resolve first.
• Define safe behavior for an expired probe-due lease. Clearing it may be permitted after confirmation, but must remain atomic and must not be described as a successful capacity check.
• Do not launch a vendor CLI, consume a model request, claim or mutate a work item, contact GitHub, or modify Local Markdown data.
• Require no worker restart. Subsequent automatic candidate selection should observe the updated shared provider state.
• Do not delete or rewrite unrelated provider entries.
• Emit human and versioned JSON results that distinguish cleared, already-available, not-recorded, and blocked-by-active-probe outcomes.

Confirmation and warning

This is a consequential operational override: clearing an open circuit can immediately permit continuous workers to start paid or quota-consuming agent processes.

• Print that warning before mutation.
• Require interactive confirmation by default.
• Require --yes in JSON or non-interactive mode.
• Selection of an agent and the clear-circuit verb is not, by itself, blanket consent for unrelated provider or work-item changes.

Corrupt-state boundary

This command must not silently treat malformed, unsupported, or structurally invalid provider state as an empty store. Existing fail-closed behavior protects against uncontrolled provider launches.

If the provider availability file cannot be read safely:

• return the existing corruption diagnostic;
• do not replace or delete it; and
• direct the operator toward a separately designed repair workflow.

A future corrupt-store repair command should preserve diagnostic evidence, account for all provider entries and locks, and use stronger break-glass confirmation. It is intentionally outside this issue.

Backend behavior

• Provider availability is installation-local and backend-neutral; the same record can affect workers processing GitHub and Local Markdown items on that installation.
• The command does not alter GitHub labels, Projects, issues, claim comments, or cached GitHub session records.
• The command does not alter Local Markdown work-item files, claims, sessions, or .runtime-state.json.
• Current-backend detection must not hide or reinterpret the installation-wide effect.

Out of scope

• Clearing provider state as part of wrighty cache clear.
• Resetting actual provider quota, billing, subscription, authentication, or account settings.
• Clearing or replacing corrupt provider availability files.
• Cancelling a live provider process or stealing an unexpired probe lease.
• Retrying, rescheduling, or changing one work item directly.
• Resetting session, workspace, claim, installation identity, or node-ID cache state.
• Web UI controls; a future operations UI may consume the same guarded operation separately.

Acceptance criteria

• A confirmed command can atomically clear one readable unavailable-until provider circuit without invoking the provider or tracker backend.
• The stored transition records operator override semantics and does not claim that a probe or provider run succeeded.
• The command is installation-local and behaves identically when invoked from GitHub, Local Markdown, or non-repository directories.
• Already-available and absent records produce explicit idempotent no-op results.
• An unexpired probe-due lease blocks the override without changing any provider state.
• Expired probe-lease behavior is explicit, tested, and cannot affect a newer concurrent lease.
• Corrupt or unsupported provider state continues to fail closed and is never discarded by this command.
• Other provider records and every non-provider cache/runtime file remain byte-for-byte unchanged.
• Human and versioned JSON output report the result without exposing account data or raw provider responses.
• Interactive and non-interactive confirmation behavior is tested.
• Tests cover cross-process contention, state changes between confirmation and mutation, active and expired probe leases, absent/available/unavailable records, corruption, both backend contexts, and invocation outside a repository.
• CLI help and provider-recovery documentation explain when to probe, when an override is justified, and the risk that automatic paid runs may resume immediately.
• Add a concise user-facing entry to the [Unreleased] changelog when implemented.