fix(cli): deliver the Bedrock API key through a named provider

[darko-mesaros]

Fixes #87190

The Bedrock API-key flow put the bearer token in OPENAI_API_KEY and set a bare provider: custom. Since #28660 that variable is only honoured for openai.com hosts, so for bedrock-mantle.*.api.aws the token was dropped and requests went out with api_key="no-key-required".

Writes a named provider instead:

model:
  provider: custom:bedrock-mantle
providers:
  bedrock-mantle:
    base_url: https://bedrock-mantle.us-east-1.api.aws/v1
    key_env: AWS_BEARER_TOKEN_BEDROCK

The named-provider branch in runtime_provider.py resolves key_env; the bare-custom branch can't. It also stops writing a Bedrock credential into another vendor's env var, which is what #28660 was guarding against anyway.

Scope: authentication only. Picking a model whose mantle route isn't /v1 still fails. #65076 covers that, and the two are independent.

Tests: tests/hermes_cli/test_bedrock_mantle_key_env.py runs the real setup flow against a temp HERMES_HOME, then hands the config it wrote to resolve_runtime_provider and asserts the token comes out instead of the placeholder. The bug lived in that seam, so testing either half alone would have missed it.

Manual: verified end to end on a live account in us-east-1, using hermes model > Bedrock > API Key and then a real prompt through the gateway on openai.gpt-5.6-terra.

Tested on Linux.

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

fix(cli): deliver the Bedrock API key through a named provider

1. No migration path for existing installs: users who ran the old wizard have provider: custom + model.base_url (bedrock-mantle) in config.yaml plus OPENAI_API_KEY/OPENAI_BASE_URL in .env. After this change those configs stay on the old shape, and since the OPENAI_API_KEY / OPENROUTER_API_KEY leak to non-OpenAI custom-provider base_urls (cross-provider credential leak) #28660 gate keeps OPENAI_API_KEY pinned to openai.com hosts, they remain broken (requests go out as no-key-required) until the user re-runs setup or manually sets AWS_BEARER_TOKEN_BEDROCK. Consider a one-time migration that detects the legacy Bedrock shape (provider == "custom" with a bedrock-mantle base_url) and rewrites it to the named-provider form, or at minimum a startup warning pointing at the new variable.

2. Token persistence: the diff removes save_env_value("OPENAI_API_KEY", existing_key) and save_env_value("OPENAI_BASE_URL", mantle_base_url) and adds nothing to persist the token. The new flow relies on AWS_BEARER_TOKEN_BEDROCK already being in the environment. For a first-time wizard run where the user pastes a token interactively, verify the token is actually persisted somewhere (.env as AWS_BEARER_TOKEN_BEDROCK, or auth.json); otherwise the wizard succeeds but the very next run authenticates with nothing.

3. test_resolution_fails_closed_when_the_token_is_absent only asserts resolved["api_key"] != TOKEN. It would pass even if the resolver fell back to some other live credential in the environment (e.g. OPENROUTER_API_KEY set in CI) rather than resolving to the intended placeholder/empty value. Since the whole point of the test is fail-closed behavior, assert the exact resolved value (empty string or the placeholder) so a fallback regression is caught.

4. The test suite itself is well constructed — driving the real wizard flow with monkeypatched prompts and then running the actual resolve_runtime_provider on the saved config is exactly the E2E seam that bug lived in.