fix(auxiliary_client): consult ProviderProfile.api_mode in resolver

[Kyzcreig]

Plugin providers that declare api_mode='anthropic_messages' with a plain base_url (no /anthropic suffix) silently land on the OpenAI-wire transport and 404 from chat/completions, because _resolve_task_provider_model only returns the task-config api_mode and never consults the provider profile. _endpoint_speaks_anthropic_messages only catches /anthropic-suffixed URLs, missing plain-base-URL Anthropic endpoints (e.g. local proxies on 127.0.0.1:PORT). This falls back to profile.api_mode when no task override is set (task config still wins), wrapped in try/except. Includes a 3-case regression test (test_aux_resolver_api_mode.py).

[alt-glitch]

Duplicate of #24586 — same fix (consult ProviderProfile.api_mode in resolver), same author, same file. Resubmission of earlier PR.

[teknium1]

Thanks for the focused resolver fix. The premise remains valid on current main: agent/auxiliary_client.py:5913-5914 initializes the result from task config only, and the client router uses OpenAI wire unless it receives anthropic_messages or identifies an Anthropic URL (agent/auxiliary_client.py:1543-1551).

Problems

• The added guard only reads the explicit provider argument. For the documented per-task route, auxiliary.<task>.provider is selected as cfg_provider at agent/auxiliary_client.py:5986; the proposed guard would not run, so a plain-base-URL profile with api_mode="anthropic_messages" remains unwrapped.
• tests/agent/test_aux_resolver_api_mode.py covers the explicit-provider case and an explicit task override, but not the configured-provider fallback above.

Suggested changes

• Apply the profile fallback to the effective selected provider (provider or cfg_provider) after config resolution, only when cfg_api_mode is empty.
• Add a configured auxiliary.<task>.provider regression case with a profile-only anthropic_messages declaration.

This is an automated hermes-sweeper review.