fix(dashboard): clear the model mirror when its custom endpoint is deleted

[Frowtek]

What does this PR do?

activate_custom_endpoint copies the endpoint's base_url and api_key onto
cfg["model"]. delete_custom_endpoint pops the providers entry and saves — it
never touches that mirror.

So deleting the endpoint the agent is currently using leaves both behind:

DELETE /api/providers/custom-endpoints/acme  -> 200
providers entry gone : True
model.api_key        : sk-CUSTOM-ENDPOINT-SECRET
model.base_url       : https://llm.acme.corp/v1

Two consequences, both silent:

• The agent keeps authenticating to the deleted host with the deleted key.
  model.api_key outranks the environment at client construction, so it also
  shadows whatever the operator configures next — the persistent-401 shape
  credential_lifecycle.py documents as [Bug]: "API key updated in UI but old key persists in config.yaml, causing authentication failures" #62269.
• A credential the operator just removed through the dashboard stays sitting in
  config.yaml.

Introduced with the custom-endpoint settings feature (#67759).

Related Issue

Fixes #

Type of Change

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

Changes Made

• hermes_cli/web_server.py — _detach_main_model_from_provider() scrubs the
  main-slot provider / base_url / api_key on delete, only when model
  actually names the deleted provider. An endpoint deleted while a different one
  is active leaves that active assignment untouched.
• tests/hermes_cli/test_web_server.py — both directions.

Testing

test_deleting_the_active_custom_endpoint_clears_its_model_mirror fails on
main, showing the stale mirror verbatim:

{'api_key': 'sk-acme-secret', 'base_url': 'https://llm.acme.corp/v1',
 'default': 'acme/model-1', 'provider': 'acme'}

test_deleting_an_inactive_custom_endpoint_leaves_the_active_one_alone passes both
ways — that's what shows the scrub is targeted, not a blanket wipe.

Web-server / model-switch / config / credential-lifecycle / dashboard-auth suites
baseline-compared against a clean origin/main worktree: identical 16 pre-existing
failures, 660 → 662 passed.

Checklist

• Bug is reproducible on main and covered by a failing-before/passing-after test
• No regressions in the surrounding suite (baseline-compared against origin/main)
• Change is scoped to the defect — no unrelated refactoring
• Tested on Ubuntu 24.04

[teknium1]

Merged via PR #68074 with your commit's authorship preserved in git log (rebase-merge). This PR went conflict-dirty after #67806 landed first — all three dashboard PRs inserted tests at the same anchor in test_web_server.py — so it was cherry-picked onto current main rather than merged directly. Thanks for the whole cluster, these were clean, well-tested fixes.