…call

When a fallback_model entry names a provider defined in custom_providers
but omits an explicit base_url, the resolution path skipped the
custom_providers lookup entirely.  If the provider name happened to alias
to a built-in (e.g. "kimi" -> "kimi-coding"), _get_named_custom_provider
would return None inside resolve_provider_client (because auth.resolve_provider
succeeds for aliases and short-circuits the search), and the code fell
through to the PROVIDER_REGISTRY path which used the built-in endpoint —
typically the same as the primary provider's base_url.

Fix (_try_activate_fallback in run_agent.py): when fb_base_url_hint is
absent, call _get_named_custom_provider with the original fb_provider name
(pre-normalization) so the custom_providers entry is found even when the
name aliases to a registered built-in.  api_key and key_env are resolved
from the same entry.

Fix (resolve_provider_client in agent/auxiliary_client.py): in the
API-key provider path, honour explicit_base_url and explicit_api_key when
provided so that the correct custom endpoint is used even after the
provider name has been normalised to a built-in alias.