fix(runtime-provider): accept api_key_env alias in named custom providers

[liuhao1024]

What does this PR do?

Accepts the api_key_env config alias in _get_named_custom_provider(), so providers defined under providers: (or legacy custom_providers:) using the documented api_key_env: field correctly resolve the API key instead of silently falling through to "no-key-required" → 401.

Related Issue

Fixes #44666

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• hermes_cli/runtime_provider.py: Accept api_key_env as an alias for key_env in three locations — the providers: dict scan (line 542), the legacy custom_providers: list scan (line 629), and the _resolve_named_custom_runtime key_env candidate (line 761). Matches the pattern already used in auxiliary_client.py:3652.
• tests/hermes_cli/test_user_providers_model_switch.py: Three regression tests — api_key_env in providers dict, priority when both key_env and api_key_env are set, and api_key_env in legacy custom_providers list.

How to Test

1. Define a provider with api_key_env: in config.yaml:

   providers:
     myprovider:
       base_url: http://127.0.0.1:56673/v1
       api_key_env: MY_API_KEY

2. Set MY_API_KEY=sk-test in .env
3. hermes config set model.provider myprovider — should NOT send "no-key-required" as bearer token
4. Run: python -m pytest tests/hermes_cli/test_user_providers_model_switch.py -k api_key_env -xvs

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Code Intelligence

• Analyzed: hermes_cli/runtime_provider.py — _get_named_custom_provider() (callers: 8), _resolve_named_custom_runtime() (callers: 3)
• Blast radius: LOW — adds alias acceptance; no behavioral change for existing key_env users
• Related patterns: auxiliary_client.py:3652 already checks both key_env and api_key_env; runtime_provider.py:1544 iterates both keys for error messages

[alt-glitch]

Duplicate of #44667 (earliest open PR for the same fix). Both accept the api_key_env alias in _get_named_custom_provider() (hermes_cli/runtime_provider.py) so providers: entries resolve the key instead of falling through to no-key-required. Same approach, same file. Linking for reviewer consolidation.

[liuhao1024]

Closing as duplicate of #44667 which was opened earlier and covers the same fix (api_key_env alias in _get_named_custom_provider). Both PRs take the same approach — no advantage to keeping both open.