Summary

• salvage helix4u's Z.AI setup fix onto current main
• route zai through a dedicated _model_flow_zai() so setup/model selection uses resolve_api_key_provider_credentials("zai")
• introduce shared base-URL override management for provider setup flows instead of making override recovery a Z.AI-only special case
• align runtime and provider-status resolution so Z.AI uses the same resolved/persisted endpoint contract end-to-end

Architecture

This PR now uses a shared _configure_base_url_override(...) helper in hermes_cli/main.py.

That helper gives provider setup flows a consistent way to:

• keep an existing explicit base URL override
• clear a stale explicit override and return to auto/default resolution
• replace the override with a new manual URL

The helper is used by:

• generic API-key provider setup flow
• Kimi setup flow
• Z.AI setup flow

For Z.AI, resolve_api_key_provider_credentials(..., ignore_env_base_url=True) was added so setup can ask: "what endpoint would auto resolution choose if I clear the explicit override?" That lets hermes model recover from stale GLM_BASE_URL values instead of trapping users on them.

The follow-up fixes also align the rest of the stack:

• resolve_runtime_provider() now honors the resolved/persisted Z.AI endpoint instead of silently falling back to the static default
• get_api_key_provider_status() now reuses resolve_api_key_provider_credentials() so status output stays consistent with setup/runtime

Why

The original PR identified a real setup/runtime mismatch: runtime/auth already knew how to autodetect the correct Z.AI endpoint family, but the interactive setup flow still treated Z.AI like a generic API-key provider and prompted for a base URL.

During review, two follow-up issues surfaced:

1. removing the manual override path only for Z.AI would create a regression for users with stale GLM_BASE_URL values
2. even after setup autodetected and persisted the correct Z.AI endpoint, runtime/status still had stale parallel base-url resolution paths

The fix here is broader and cleaner: shared override-management UX for provider setup flows, with provider-specific autodetection beneath it, and aligned runtime/status resolution so the chosen endpoint is actually used everywhere.

Current-main follow-ups included

• preserved newer dispatch entries on main (including nvidia / ollama-cloud) while carving out zai
• added dispatch-level regression coverage on top of the original setup-flow tests
• added tests for shared base-URL override management
• added tests proving Z.AI setup can manually set an override and can clear a stale override back to the autodetected endpoint
• added tests proving provider status uses the resolved Z.AI endpoint
• added tests proving runtime uses the Z.AI endpoint persisted in config

Test plan

• scripts/run_tests.sh tests/hermes_cli/test_api_key_providers.py -k 'zai or GLM_BASE_URL or detect_zai_endpoint or runtime_zai or provider_status' -q
• scripts/run_tests.sh tests/hermes_cli/test_model_provider_persistence.py tests/hermes_cli/test_api_key_providers.py tests/hermes_cli/test_setup.py tests/hermes_cli/test_setup_model_provider.py tests/hermes_cli/test_ollama_cloud_provider.py -q
• E2E-style isolated import/config checks:
  • manual Z.AI base URL override persists correctly
  • stale GLM_BASE_URL can be cleared and falls back to the autodetected endpoint
  • runtime resolves zai using the persisted config base URL instead of the static default

Based on #11376 by @helix4u.