[FEATURE]:Native API Key Pool & Automatic Failover to Prevent Rate Limit Task Failures

Problem

Currently, OpenCode only supports a single API key per model provider. When that key hits a rate limit (HTTP 429), runs into a server error (500), or exhausts daily quota, any active agent task stops immediately with no way to recover automatically.

For long, complex coding tasks, this is very disruptive — you lose progress mid-work and have to manually restart the session, which defeats the purpose of an autonomous coding agent. There's no built-in way to work around rate limits short of manually swapping keys, which breaks the native workflow.

I know issue #7602 covers model-level fallback, but this request focuses specifically on key-level pooling and failover within the same provider/model, which is a more targeted fix for everyday rate limit issues.

Proposed Solution

Add a native API key pool manager directly at the LLM adapter layer, with these core capabilities:

1. Multi-key rotation: Let users configure a list of multiple API keys for the same provider, with round-robin distribution to spread out request load.
2. Instant failover: Automatically retry requests that return 429 or 500 status codes with a different key from the pool, so the agent loop continues without interruption.
3. Smart cooldown: Temporarily remove throttled keys from rotation for a short window (default 60s, or following the Retry-After response header if provided).
4. Quota tracking: Automatically disable keys that hit their daily quota limit until midnight UTC reset, with an option for manual re-enablement.
5. TUI status display: Show real-time key status (active / cooling down / quota exhausted) directly in the terminal interface for transparency.

Additional Notes

Separately, I think there are other worthwhile efficiency improvements for OpenCode — like better prompt caching via context diffing, a tree-sitter based repo map to reduce context bloat, and per-step reasoning effort controls. I've focused this issue on key pooling since it's the most immediate reliability problem for me, but I can open separate, focused issues for those other ideas if there's interest.