Health check blocks pi/OpenAI-only runs on Anthropic outages

Hit live during a benchmark run on 2026-07-17: Anthropic's status page reported a disruption, and the wizard refused to start pi-harness orchestrator runs (wizard-use-pi-harness=true, gpt-5.6 models) that never call Anthropic:

label=base-memos elapsed=2s outro=NO   <- health-check abort
label=r3-memos   elapsed=3s outro=NO   <- pi/OpenAI-only, blocked anyway

DEFAULT_WIZARD_READINESS_CONFIG in src/lib/health-checks/readiness.ts blocks every run when Anthropic is down — and even when merely degraded — regardless of which harness the run resolves to:

downBlocksRun: ['anthropic', 'npmOverall', 'llmGateway', 'mcp', 'githubReleases'],
degradedBlocksRun: ['anthropic'],

The precedent already exists in the same file: SIGNUP_WIZARD_READINESS_CONFIG narrows the blocking set for provisioning flows because "it doesn't use Anthropic directly". The run readiness config could do the same — gate on the providers the resolved harness actually uses.

Start in src/lib/health-checks/readiness.ts and compare DEFAULT_WIZARD_READINESS_CONFIG with SIGNUP_WIZARD_READINESS_CONFIG. Trace how the resolved harness identifies the providers a run uses, then adjust readiness gating so an Anthropic outage does not block pi/OpenAI-only runs. Done means those runs can start during Anthropic downtime while providers they actually use remain blocking.