fix(cli): accept api_key_env alias in providers entries

[Code-suphub]

Summary

When defining a named custom provider under providers: in config.yaml using the documented api_key_env field, the key resolution silently ignores it because only key_env is checked. This causes 401 errors — "no-key-required" is sent as the bearer token.

Fixes #44666

Root Cause

_get_named_custom_provider() in runtime_provider.py (lines 542, 629) only checks entry.get("key_env"). The same gap exists in model_switch.py line 1783 and config.py line 3852.

Other code paths already handle both aliases correctly:

• agent/auxiliary_client.py:3652 — custom_entry.get("key_env") or custom_entry.get("api_key_env")
• agent/agent_init.py:833 — _fb.get("key_env") or _fb.get("api_key_env")
• hermes_cli/config.py:3786 — normalizes api_key_env → key_env for camelCase keys

Changes

File	Change
hermes_cli/runtime_provider.py	Add api_key_env fallback in 3 locations
hermes_cli/model_switch.py	Add api_key_env fallback in provider resolution
hermes_cli/config.py	Add api_key_env fallback in entry normalization

Testing

# Verify the fix pattern matches existing usage
grep -n "api_key_env" hermes_cli/runtime_provider.py
grep -n "api_key_env" hermes_cli/model_switch.py
grep -n "api_key_env" hermes_cli/config.py

The same class of bug was fixed for fallback_providers: in #25091 (commit 6ddc48b0).

Type of Change

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

Checklist

Code

• I have read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope): description)
• I searched for existing PRs to make sure this is not a duplicate
• My PR contains only changes related to this fix (no unrelated commits)
• I have considered cross-platform impact (Windows, macOS, Linux) per the compatibility guide

Documentation

• I have updated relevant documentation or marked as N/A
• I have updated cli-config.yaml.example if I added/changed config keys or marked as N/A

[tonydwb]

Clean backward-compat fix. Accepts api_key_env as alias for key_env in provider config entries, updated in 3 locations (config.py, model_switch.py, runtime_provider.py). Allows users with older configs using api_key_env to continue working. No issues found.

[alt-glitch]

Duplicate of #44667 (earliest open) — same fix for #44666: accept the api_key_env alias in _get_named_custom_provider. #44768 is also a duplicate; #44669 was closed.

[teknium1]

Thanks for tracing the raw providers: path — the reported runtime failure remains reproducible by inspection on current main: hermes_cli/runtime_provider.py:668 reads only key_env, and the fallback chain reaches "no-key-required" at :1013-1030.

Problems

• The change misses the explicit model-switch credential path. hermes_cli/model_switch.py:1185-1193 reads the raw provider entry and only resolves key_env; the edited picker-probe path does not cover that request-time flow.
• hermes_cli/providers.py:606-617 also exposes only key_env, although resolve_provider_full() returns that user-provider definition at :738-740.
• No regression test is included. Current end-to-end coverage at tests/hermes_cli/test_runtime_provider_resolution.py:1003-1040 exercises only key_env; alias tests at :2577-2610 cover normalization, not this raw runtime path.
• The config.py normalization is already on current main at hermes_cli/config.py:4715-4716, so that hunk is redundant.

Suggested changes

• Apply one canonical-first alias resolver to the runtime, explicit model-switch, and provider-definition consumers.
• Add api_key_env behavior tests for runtime and explicit switching, including key_env precedence.

Automated hermes-sweeper review.