Summary

Fixes #16290

When auxiliary.vision.provider is set to a named provider (e.g. zai) with a custom base_url, the credential pool was not consulted for that provider's API key. The provider was silently forced to custom and only OPENAI_API_KEY was checked, causing 401 errors.

Root Cause

_resolve_task_provider_model() forced provider='custom' whenever cfg_base_url was set, discarding the original named provider. resolve_vision_provider_client() then only looked up credentials from the custom pool.

Changes

1. _resolve_task_provider_model() — when both cfg_provider and cfg_base_url are set, preserve the named provider instead of forcing 'custom'
2. resolve_vision_provider_client() — when a named provider accompanies a base_url, resolve credentials from that provider's pool via the new _resolve_provider_api_key() helper
3. _resolve_provider_api_key() — new helper that consults PROVIDER_REGISTRY + resolve_api_key_provider_credentials() to get the right key for a named provider

Test Coverage

8 new tests in test_vision_provider_base_url_credentials.py:

• Provider preserved when both provider + base_url configured
• Falls back to 'custom' when only base_url is set
• 'auto' provider not preserved with base_url
• ZAI_API_KEY resolved from env for provider='zai'
• Unknown provider returns None
• Provider with no key returns None
• Vision client uses zai credentials with base_url
• Custom provider skips credential pool lookup

All 96 existing auxiliary tests continue to pass.

Reproduction (before fix)

auxiliary:
  vision:
    provider: zai
    model: glm-4v
    base_url: https://open.bigmodel.cn/api/paas/v4
    api_key: ''    # leave empty, expecting auto-resolve

Previously: 401 error. After fix: ZAI_API_KEY from .env is used.