fix(auxiliary): preserve named provider on custom endpoint

[LeonSGP43]

What does this PR do?

Fixes auxiliary provider resolution so auxiliary.<task>.provider is preserved when base_url and api_key are both configured. Previously this path forced provider to "custom", which skipped provider-specific handling in downstream call logic.

Related Issue

Fixes #26879

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• Updated _resolve_task_provider_model() in agent/auxiliary_client.py:
  • when cfg_base_url + cfg_api_key are both set, preserve explicit non-auto cfg_provider instead of forcing "custom".
• Added regression tests in tests/agent/test_vision_resolved_args.py:
  • verifies named provider is preserved for custom endpoint configs
  • verifies provider: auto still resolves to "custom" for this path

How to Test

1. Run:
   python3 -m pytest -o addopts='' tests/agent/test_vision_resolved_args.py
2. Confirm all tests pass.
3. Verify behavior from config:
   set auxiliary.vision.provider=zai with base_url + api_key and confirm resolved provider remains zai.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS 15.x

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Screenshots / Logs

4 passed in 0.63s

[alt-glitch]

Duplicate of #9288 — same root cause: _resolve_task_provider_model() forces provider to "custom" when base_url + api_key are both set, discarding the explicit named provider. Multiple competing PRs exist for this fix: #10823, #16389, #14718, #16727.

[teknium1]

Thanks for isolating the remaining configuration-resolution branch. The reported defect still exists on current main at agent/auxiliary_client.py:5978-5980, where a configured provider is discarded when both base_url and api_key are set.

Problems

• agent/auxiliary_client.py:3989 preserves every non-auto value, including unknown provider names. Current main's related routing policy is deliberately narrower: _preserve_provider_with_base_url() at agent/auxiliary_client.py:5930-5950 preserves only recognized provider-backed routes; unknown values otherwise route as custom. An unknown provider reaches the no-client return in resolve_provider_client() at agent/auxiliary_client.py:4870-4877.

Suggested changes

• Apply the current-main guard to cfg_provider in this config-derived branch, retaining custom for unrecognized, custom, and auto values. Add a regression case for an unknown provider alongside the existing Z.AI and auto cases.

Automated hermes-sweeper review.

[teknium1]

Please preserve this identity only for a recognized provider-backed route. Current main's _preserve_provider_with_base_url() keeps unknown/custom values on the generic custom path; otherwise an unknown configured name reaches resolve_provider_client()'s no-client branch instead of using the explicit endpoint.