fix(auxiliary): pass cfg_base_url/cfg_api_key for named providers, prevent force-routing to custom

[hookinglau]

Problem

Two bugs in agent/auxiliary_client.py cause auxiliary tasks (vision, compression, etc.) to fail with 401 when using a named provider with base_url set in config.

Bug 1 (reported in #20139)

_resolve_task_provider_model drops cfg_base_url and cfg_api_key when returning a named provider, so configured API keys are lost.

Bug 2

async_call_llm unconditionally passes base_url to resolve_vision_provider_client. This triggers _resolve_task_provider_model line 3800 (if base_url: return "custom"), which force-routes through the "custom" provider path that only checks OPENAI_API_KEY — ignoring provider-specific env vars like DASHSCOPE_API_KEY.

How to reproduce:

auxiliary:
  vision:
    provider: alibaba
    model: qwen-vl-max
    base_url: https://dashscope.aliyuncs.com/compatible-mode/v1  # triggers bug

Send an image via WeChat → 401 despite valid DASHSCOPE_API_KEY in .env.

Fix

1. _resolve_task_provider_model: pass cfg_base_url and cfg_api_key for named providers (one-line change, closes fix(auxiliary): pass cfg_base_url and cfg_api_key when resolving task provider #20139)
2. async_call_llm: only pass base_url to resolve_vision_provider_client when provider is "custom", preventing known providers from being force-routed through the custom path

Testing

• Verified: WeChat image sends no longer return 401 after fix
• Verified: auxiliary.vision with provider=alibaba, no base_url in config (existing working case) continues to work

[alt-glitch]

Duplicate of #20139 (same fix: pass cfg_base_url and cfg_api_key when resolving named provider in auxiliary_client). Also overlaps with #16727 which addresses the same force-routing to custom path.

[teknium1]

Merged via PR #24619. Your commit was cherry-picked onto current main with your authorship preserved. Tests passed (155/155). Thanks for the fix!