hermes - 💡(How to fix) Fix Bug: vision fallback_chain silently broken — wrong kwargs in _resolve_single_provider

Bug

_resolve_single_provider() (line 2652) passes base_url and api_key to resolve_provider_client(), but that function expects explicit_base_url and explicit_api_key. This causes a TypeError that is silently swallowed, returning None for the client — so the entire configured fallback_chain for auxiliary tasks (vision, etc.) never fires.

Impact

When the primary vision provider (e.g. Gemini) returns 429/402, the configured auxiliary.vision.fallback_chain entries are skipped due to this TypeError, and the error propagates directly to the user instead of trying the configured fallback providers.

Reproduction

1. Configure auxiliary.vision.fallback_chain with a valid provider (e.g. Xiaomi-TP)
2. Primary provider (Gemini) returns 429
3. Fallback chain silently fails — no fallback attempt

Fix

# Before (broken):
client, resolved_model = resolve_provider_client(
    provider=provider,
    model=model,
    base_url=base_url,
    api_key=api_key,
)

# After (fixed):
client, resolved_model = resolve_provider_client(
    provider=provider,
    model=model,
    explicit_base_url=base_url,
    explicit_api_key=api_key,
)

Verified

After the fix, _try_configured_fallback_chain('vision', 'gemini', 'payment error') correctly returns an OpenAI client with model mimo-v2-omni via fallback_chain[0](Xiaomi-TP).