Bug Description

In agent/auxiliary_client.py, resolve_provider_client() receives an explicit_api_key parameter and correctly propagates it to most downstream provider calls. However, when routing to OpenRouter, it calls _try_openrouter() without passing explicit_api_key, silently ignoring it.

This causes auth failures when the auxiliary client falls back to OpenRouter using a runtime API key from the credential pool.

Steps to Reproduce

1. Configure a credential pool entry for openrouter with a valid runtime API key
2. Set a main provider (e.g., openai or openrouter) with OPENAI_API_KEY
3. When the main call fails and the system falls back to openrouter via resolve_provider_client()
4. OpenRouter fallback uses env var OPENROUTER_API_KEY (may be empty) instead of the pool's runtime key

Expected Behavior

OpenRouter fallback should use the explicit_api_key passed to resolve_provider_client, just like all other providers do.

Root Cause Analysis

File: agent/auxiliary_client.py, line ~2052

def resolve_provider_client(
    provider: str,
    ...
    explicit_api_key: str = None,  # received here
    ...
):
    ...
    if provider == "openrouter":
        client, default = _try_openrouter()  # explicit_api_key dropped!

The _try_openrouter() function has no parameter to accept explicit_api_key, so even callers that want to pass it cannot.

Proposed Fix

1. Add explicit_api_key: str = None parameter to _try_openrouter()
2. Use explicit_api_key or os.getenv("OPENROUTER_API_KEY") as the key source
3. Update call site: _try_openrouter(explicit_api_key=explicit_api_key)

Affected Component

• Agent Core (conversation loop, context compression, memory)

Environment

• Hermes v0.12.0 (v2026.4.30)