Summary

Add configurable fallback_chain for auxiliary tasks so that when a configured provider fails (quota, rate-limit, connection), the system automatically tries alternative providers instead of raising immediately.

Closes #26882

Problem

Currently, auxiliary task fallback only works when resolved_provider is "auto" (no explicit provider configured). When a user explicitly configures an auxiliary task (e.g., auxiliary.vision.provider: glm), the is_auto gate at the fallback entry point prevents any fallback:

is_auto = resolved_provider in {"auto", "", None}
if should_fallback and is_auto:  # ← blocks explicit-provider users

This means a user who configures auxiliary.vision.provider: glm gets zero recovery when glm fails — the error propagates directly.

Solution

1. New config key: auxiliary.<task>.fallback_chain — a list of {provider, model, base_url?, api_key?} entries
2. New function: _try_configured_fallback_chain() — reads the chain from config, tries each entry via resolve_provider_client()
3. Modified fallback gate: Removed the is_auto requirement from the outer gate; auto-chain runs first (existing behaviour), then configured chain runs as fallback

Config example

auxiliary:
  vision:
    provider: glm
    model: glm-4v-flash
    fallback_chain:
      - provider: openrouter
        model: google/gemini-3-flash-preview
      - provider: nous
        model: claude-sonnet-4
  compression:
    provider: openrouter
    fallback_chain:
      - provider: openai
        model: gpt-4o-mini

Behaviour

1. Try primary provider first (unchanged)
2. On fallback-worthy errors (429, 402, connection), try auto-detection chain (unchanged for auto users)
3. New: If auto-chain doesn't find a fallback (or user has explicit provider), try fallback_chain entries in order
4. If all entries fail, raise the last error

Files Changed

Test Results

295 passed, 1 skipped, 23362 deselected (all auxiliary tests)

Design Decisions

• Config over code: Users define fallback chains in config.yaml, not in Python
• Non-breaking: Existing auto fallback behaviour is unchanged; fallback_chain is purely additive
• Task-agnostic: Works for ALL auxiliary tasks (vision, tts, compression, web_extract, etc.)
• Reuses resolve_provider_client(): No duplicate provider resolution logic