fix(auxiliary): bridge runtime credentials into vision auto-detect (sibling gap of #35259)

[arxeme]

What does this PR do?

Fixes vision_analyze failing with No LLM provider configured for task=vision provider=auto for users whose main provider is a named custom provider (custom:<name>), even though normal chat and every other auxiliary task work.

This is the sibling gap of #35259. That PR taught set_runtime_main() to record base_url/api_key/api_mode and bridged them in _resolve_auto() — but the parallel vision path in resolve_vision_provider_client() was never updated, so vision alone still loses the credentials.

Related Issue

Fixes #43251

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• agent/auxiliary_client.py — in the resolve_vision_provider_client() auto branch, forward _RUNTIME_MAIN_BASE_URL / _RUNTIME_MAIN_API_KEY / _RUNTIME_MAIN_API_MODE into the resolve_provider_client() call as explicit_base_url / explicit_api_key / api_mode, mirroring the existing _resolve_auto() bridge.
• tests/agent/test_set_runtime_main_custom_provider.py — add TestResolveVisionUsesRuntimeGlobals::test_vision_auto_forwards_runtime_credentials asserting the vision auto path forwards the runtime credentials.

Root Cause

For a custom:<name> provider, the agent resolver flattens agent.provider to bare "custom" and carries the endpoint credentials separately. Each turn turn_context.py calls set_runtime_main("custom", model, base_url=..., api_key=..., api_mode=...), so _RUNTIME_MAIN_PROVIDER == "custom" with the credentials in _RUNTIME_MAIN_BASE_URL / _RUNTIME_MAIN_API_KEY.

• Non-vision aux → _resolve_auto() bridges those globals (added by fix(auxiliary): route custom-provider aux tasks to the user endpoint (salvage #34783) #35259) → works.
• Vision → resolve_vision_provider_client(provider="auto") reads main_provider = "custom" and called resolve_provider_client("custom", ...) without explicit_base_url/explicit_api_key. The anonymous-custom branch then finds no credentials, logs custom/main requested but no endpoint credentials found, and the chain returns None.

How to Test

Reproduced on v0.16.0 with a custom:garena-gateway-anthropic main provider (api_mode: anthropic_messages, key via key_env):

from agent.auxiliary_client import resolve_vision_provider_client, set_runtime_main
set_runtime_main("custom", "claude-opus-4-7",
                 base_url="https://<gateway>/...",
                 api_key="<key>", api_mode="anthropic_messages")
prov, client, model = resolve_vision_provider_client(provider="auto")
# before: client is None  →  "No LLM provider configured for task=vision"
# after:  client is AnthropicAuxiliaryClient

Tests:

pytest tests/agent/test_set_runtime_main_custom_provider.py -q -o 'addopts='   # 8 passed
pytest tests/agent/test_auxiliary_client.py tests/agent/test_auxiliary_main_first.py \
       tests/agent/test_auxiliary_named_custom_providers.py tests/tools/test_vision_tools.py -q -o 'addopts='   # 335 passed

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(auxiliary): …)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix
• I've run the relevant tests and they pass
• I've added tests for my changes
• I've tested on my platform: Linux (Python 3.11), v0.16.0

Documentation & Housekeeping

• Documentation update — N/A (internal routing fix)
• cli-config.yaml.example — N/A (no config keys changed)
• CONTRIBUTING.md / AGENTS.md — N/A (no architecture change)
• Cross-platform impact — N/A (pure Python, no platform primitives)
• Tool descriptions/schemas — N/A (no tool behavior change)

[tonydwb]

Code Review Summary

Verdict: Approved

✅ Looks Good

• Regression fix with test coverage: The fix bridges runtime credentials (_RUNTIME_MAIN_BASE_URL, _RUNTIME_MAIN_API_KEY, _RUNTIME_MAIN_API_MODE) into the vision auto-detect path, mirroring _resolve_auto() behavior from PR #35259.
• Clean test: TestResolveVisionUsesRuntimeGlobals covers the key assertion — that explicit_base_url, explicit_api_key, and api_mode are forwarded to resolve_provider_client when provider="auto" and the runtime main is a custom provider.
• No security issues: Test uses "***" as a placeholder API key — not a real credential.
• Well-scoped: Only 2 files changed (+50/-1), single concern.

ℹ️ Minor

• The api_mode=resolved_api_mode or (_RUNTIME_MAIN_API_MODE or None) fallback chains two falsy-check operators — this is intentional and correct (preserves explicit None from the caller while falling back to runtime global).

---

Reviewed by Hermes Agent

[teknium1]

Implemented on main; thank you for the precise diagnosis and focused regression test.

Automated hermes-sweeper review found:

• 25aa626cb42cfec620083ea69fe12e8afe171ff7 (fix(vision): forward custom-endpoint credentials in vision auto-detect) implements this runtime-credential bridge.
• agent/auxiliary_client.py:5373-5402 forwards _RUNTIME_MAIN_BASE_URL, _RUNTIME_MAIN_API_KEY, and _RUNTIME_MAIN_API_MODE for custom and custom:<name> vision auto-detect paths, and also preserves a configured-endpoint fallback.
• tests/agent/test_auxiliary_main_first.py:577-690 covers bare custom, named custom, and no-runtime configured-endpoint cases.
• The fixing commit shipped in v2026.7.7.

The linked issue #43251 was also closed with this same implemented-on-main finding.