feat: eager fallback to backup model on rate-limit errors

[usvimal]

Summary

When a fallback model is configured via fallback_model in config.yaml, the agent now switches to it immediately upon detecting rate-limit conditions instead of exhausting all retries with exponential backoff.

Problem: When the primary provider is rate-limited (429, quota exhaustion, billing cycle limit), the current retry loop burns through 3 attempts with extended backoff (5s → 10s → 20s) before trying the fallback. The primary provider is unlikely to recover within this window, so the delay is wasted.

Fix: Two eager-fallback checks are added:

1. Invalid/empty API responses (common rate-limit symptom where the provider returns a response with no choices or missing content) — fallback is attempted immediately after the first failure.

2. Exception-based rate limits (HTTP 429, quota exhaustion, usage limit, billing errors) — a new is_rate_limited check runs before the existing 413/4xx handlers and switches immediately.

Both paths are guarded by _fallback_activated to preserve the existing one-shot semantics.

Test plan

• Configure a primary model with a rate-limited/exhausted API key and a working fallback model
• Send a message — verify the agent switches to fallback on the first failure instead of retrying 3 times
• Verify non-rate-limit errors (auth failures, invalid model, etc.) still follow existing retry/abort behavior
• Verify fallback only activates once per session (one-shot guard)