fix(web): clear stale api-alias credential on provider switch in main-model assignment

[ly-wang19]

Summary

Follow-up to c253b0738 ("clear stale endpoint credentials across switches").

That commit added clear_model_endpoint_credentials() to scrub an old endpoint's inline secret — api_key, the legacy api alias, and api_mode — when the web UI switches the main model to a different provider. But _apply_main_model_assignment (hermes_cli/web_server.py) gates the key-scrub path on model_cfg["api_key"] being truthy:

if api_key.strip():
    model_cfg["api_key"] = api_key.strip()
    model_cfg.pop("api", None)
elif model_cfg.get("api_key") and new_provider != prev_provider:   # ← api_key only
    clear_model_endpoint_credentials(model_cfg, clear_api_mode=False)
if new_provider != prev_provider:
    clear_model_endpoint_credentials(model_cfg, clear_api_key=False)  # clears api_mode only

So when the stale secret lives only under the legacy api alias (no api_key), a provider switch fails that elif, and the second call uses clear_api_key=False — the secret under api is never cleared and survives in config.yaml.

This matters because model.api is a live credential read path — _resolve_openrouter_runtime() reads for k in ("api_key", "api") and feeds it as the api_key candidate on the custom/auto branch. So endpoint A's plaintext secret persists and becomes the active credential the next time resolution flows through a custom endpoint — the exact "secrets in config.yaml… contaminate later custom resolution" harm clear_model_endpoint_credentials's own docstring names.

It's also an inconsistency: the sibling persistence sites (the two gateway model-picker paths and the aux-slot path) call the helper unconditionally on a non-custom switch and already scrub api; only this caller had the api_key-only gate.

Reproduced:

_apply_main_model_assignment(
    {"provider": "custom", "api": "sk-secret-A", "base_url": "https://endpoint-A/v1"},
    "openrouter", "m",
)
# before: {"provider": "openrouter", "api": "sk-secret-A", "base_url": "", "default": "m"}  ← stale secret survives
# after:  {"provider": "openrouter", "base_url": "", "default": "m"}

Fix

Widen the guard to fire on either field:

elif (model_cfg.get("api_key") or model_cfg.get("api")) and new_provider != prev_provider:

The same-provider re-pick (preserves the key) and explicit-new-key paths are unchanged.

Tests

Added the legacy-api-alias case to test_apply_main_model_assignment_base_url_and_context_reconcile in tests/hermes_cli/test_web_server.py (asserts both api and api_key are absent after a provider switch). Fails without the fix (the api alias survives); passes with it.

[teknium1]

Thanks for the focused regression fix. The premise holds on current main: hermes_cli/web_server.py:1137 clears credentials only for a populated api_key, while hermes_cli/config.py:4571-4573 defines credential cleanup to remove both api_key and the legacy api alias. The runtime still reads both aliases at hermes_cli/runtime_provider.py:1059-1063.

The proposed guard makes the existing cleanup path cover the missing alias-only state without changing same-provider or explicit-key behavior. The added regression case directly exercises that state.

Automated hermes-sweeper review.

[teknium1]

Merged via PR #68125 with your commit's authorship preserved in git log (rebase-merge). Your fix was picked up in a post-merge sweep of the credential-hygiene cluster (#67806/#67797/#68074) — the premise held exactly as you described: the switch-clears-the-key path never fired when the stale secret lived under the legacy api alias only. Thanks for the focused fix and the test.