fix(cli): honor api_key from config.yaml for anthropic provider

[Tranquil-Flow]

What does this PR do?

Runtime provider resolution did not honor model.api_key from config.yaml for the Anthropic provider in the intended scoped path. This PR allows configured Anthropic API keys to be used for Anthropic only, avoiding cross-provider key leakage.

Related Issue

Related to Anthropic runtime provider config resolution.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• Honor model.api_key in hermes_cli/runtime_provider.py when the configured provider is Anthropic.
• Keep provider scoping strict so the configured key is not leaked to unrelated providers.
• Add focused runtime provider resolution regression coverage.

How to Test

1. Check out this PR branch.
2. Run: .venv/bin/python -m pytest -o 'addopts=' tests/hermes_cli/test_runtime_provider_resolution.py -q
3. Expected result: 131 passed

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 — focused pytest passed; full suite was not run in this salvage pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: Linux container / Python 3.11

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

Screenshots / Logs

Focused verification:

`.venv/bin/python -m pytest -o 'addopts=' tests/hermes_cli/test_runtime_provider_resolution.py -q` — 131 passed

[alt-glitch]

Likely duplicate of #11713 (closed) — same fix: honor model.api_key from config.yaml for anthropic provider. Also related to #16346, #16254 (broader api_key/api_mode config issues).

[teknium1]

Thanks for isolating the normal native-Anthropic resolution path and retaining provider scoping. The premise remains valid on current main: the non-Azure branch still calls resolve_anthropic_token() directly at hermes_cli/runtime_provider.py:1902-1903.

Problems

• The explicit-runtime sibling remains unfixed. _resolve_explicit_runtime() activates when an explicit base URL is provided (hermes_cli/runtime_provider.py:1364), but its Anthropic branch falls through to resolve_anthropic_token() at :1375-1380 without considering the scoped model.api_key.

Suggested changes

• Apply the same provider-gated config-key fallback in _resolve_explicit_runtime() before the environment/credential fallback, and add coverage for explicit base URL plus config-only key and the cross-provider no-leak case.
• Add a temp-HERMES_HOME config-loading regression test for this resolution chain.

GitHub currently reports this branch as conflicting, and the resolver has moved; salvage will require manual conflict resolution rather than a clean cherry-pick. This is an automated hermes-sweeper review.