hermes - 💡(How to fix) Fix Direct API-key providers can inherit stale local base_url after provider migration [1 pull requests]

Bug description

When migrating from a gateway/subscription route to a direct API-key provider, Hermes can keep a stale local model.base_url while model.provider is updated.

Example migration:

1. Previous route used a local gateway-style endpoint such as http://localhost:8081/v1.
2. User changes model.provider to a direct provider such as deepseek.
3. model.default is set to the provider's model slug, e.g. deepseek-v4-pro.
4. model.base_url remains set to the old local endpoint.

Hermes then sends the direct provider's model slug to the stale local route instead of the provider registry endpoint. The observed failure is misleading because it looks like a model-name problem, e.g. Unknown Model, rather than stale routing configuration.

Expected behavior

For direct API-key providers registered in Hermes' provider registry, a stale loopback model.base_url from an old local gateway route should not override the provider registry endpoint.

Actual behavior

The stale local model.base_url can continue to override the direct provider route, so the request reaches the wrong upstream and fails with confusing provider/model errors.

Impact

This makes provider migration unnecessarily hard to diagnose. The user can have the correct provider, API key, and model slug, while requests still fail because an old localhost route silently takes precedence.

Proposed fix

When agent.provider is a direct provider from PROVIDER_REGISTRY and agent.base_url points at a loopback host (localhost, 127.0.0.1, or ::1), ignore that local override and let resolve_provider_client() choose the canonical provider endpoint.

A narrow regression test should verify that deepseek plus stale http://localhost:8081/v1 routes to https://api.deepseek.com/v1 via resolve_provider_client().