Bug Description

The fallback_providers chain in run_agent.py does not resolve key_env from the config. It only reads the api_key field directly, so any fallback entry using key_env is silently treated as having no API key.

Root Cause

In run_agent.py ~line 6149:

fb_api_key_hint = (fb.get("api_key") or "").strip() or None

This only checks the api_key key in the fallback config dict. There is no lookup for key_env to resolve the actual API key from environment variables.

Note that PR #9016 fixed key_env resolution for providers: dict in runtime_provider.py and auxiliary_client.py, but the fallback chain path in run_agent.py was not covered.

Steps to Reproduce

1. Configure fallback providers using key_env in config.yaml:

   fallback_providers:
     - base_url: https://ollama.com/v1
       model: minimax-m2.7
       provider: openai-compatible
       key_env: OLLAMA_KEY_1

2. Ensure OLLAMA_KEY_1 is set in .env.
3. Trigger a rate limit on the primary provider so the fallback chain activates.
4. Observe that the fallback fails with an authentication error — the env var is never read.

Expected Behavior

When api_key is not present in the fallback config, Hermes should check key_env and resolve the API key from the specified environment variable, consistent with how providers: dict works after PR #9016.

Suggested Fix

In _try_activate_fallback() around line 6149, add key_env resolution:

fb_api_key_hint = (fb.get("api_key") or "").strip() or None
if not fb_api_key_hint:
    _key_env = fb.get("key_env")
    if _key_env:
        fb_api_key_hint = os.getenv(_key_env) or None

Workaround

Use api_key with the literal value instead of key_env:

fallback_providers:
  - base_url: https://ollama.com/v1
    model: minimax-m2.7
    provider: openai-compatible
    api_key: your-actual-key-here

Environment

• Hermes Agent: latest (post v0.8)
• Config schema: v12+
• OS: Linux (Ubuntu)