[Feature Request] Implement provider-scoped circuit breaker for shared 429 rate-limit coordination across subagents

Bug Description
Type: missing capability Title: Subagent 429 retries are a tight per-call loop, not a provider-scoped circuit breaker Area: Agent orchestration / subagents / rate limiting Failure mode: Shared-provider 429 retry amplification Details: Observed: A dispatched general-purpose subagent doing PR-body work hit: 429 Rate limited · Retrying in 0s · attempt 4/10 This showed near-immediate retries occurring inside the subagent's own request loop, with no visible provider/account-level throttle state shared with the parent or other concurrently running agents. Why this matters: Multiple agents/subagents can share the same provider account, subscription, model family, and effective quota window. If each agent independently retries a 429, one throttled request can become a retry-amplification event across the agent fleet. A 429 should reduce aggregate pressure, not cause each worker to independently probe the same constrained provider. Expected capability: Agent orchestration should maintain a provider-scoped circuit breaker keyed approximately by: provider + account/subscription + model family + rate-limit/reset window When a 429 occurs: Respect Retry-After / provider reset metadata when available. Otherwise use bounded exponential backoff with jitter. Publish shared throttle state so sibling agents using the same quota stop independent retries. Disable worker-local retry loops while the circuit is open. Allow one parent/Conductor-owned recovery probe after cooldown. Gradually release affected workers after a successful probe rather than generating a simultaneous retry burst. Preserve each subagent's durable task/checkpoint state during cooldown and resume from the next unfinished event instead of redispatching/reconstructing the task. Important distinction: Per-agent retry discipline is not sufficient here. The missing capability is harness-level shared provider-pressure coordination across subagent boundaries. Observed context: MVP-Core multi-agent orchestration with CA1-CA4/Gatekeeper; the specific attempt 4/10 event occurred in the single dispatched CA3 continuation worker handling issue #7337. No duplicate worker was intentionally launched. Cause: Not diagnosed. This report describes observed harness behavior and the missing coordination primitive; it does not claim a specific implementation root cause. Desired invariant: SHARED PROVIDER QUOTA -> SHARED RETRY AUTHORITY RESOURCE PRESSURE -> CONTAIN -> PRESERVE -> YIELD -> RESUME Reproduction: Under provider/account pressure, dispatch a subagent that performs model-backed work and observe its 429 handling. The reported session produced the exact message above. Cross-agent behavior should additionally be tested with multiple agents sharing the same provider/account quota to verify that one 429 opens shared throttle state rather than independent retry loops.

Environment Info

• Platform: win32
• Terminal: windows-terminal
• Version: 2.1.263
• Feedback ID: fbb5a8e1-36b2-4771-afd4-a14603cb063e

Errors

[{"error":"Error: EBUSY: resource busy or locked, open 'E:\\source\\MechSolATL\\MVP-Core\\AgentOrchestration\\Locks\\boot-transaction.lock'\n    at async <anonymous> (node:fs/promises:179:56)\n    at async vt (B:/~BUN/root/chunk-b8n3wdc0.js:11:2086)\n    at async TVt (B:/~BUN/root/chunk-b8n3wdc0.js:11:4244)\n    at async <anonymous> (B:/~BUN/root/chunk-wxm61xb2.js:1162:855)\n    at async rio (B:/~BUN/root/chunk-wxm61xb2.js:1162:5566)\n    at async Din (B:/~BUN/root/chunk-wxm61xb2.js:1162:928)\n    at async eio (B:/~BUN/root/chunk-wxm61xb2.js:1160:18222)\n    at async x6o (B:/~BUN/root/chunk-wxm61xb2.js:3220:2615)\n    at async run (B:/~BUN/root/chunk-wxm61xb2.js:1224:1643)\n    at async <anonymous> (B:/~BUN/root/chunk-m8qyvwrt.js:333:3860)","timestamp":"2026-09-06T17:56:54.387Z"}]