fix(auxiliary_client): route minimax-oauth through the auxiliary path

[rgoza1996]

The auxiliary client in agent/auxiliary_client.py resolves provider clients for background tasks like title generation, compression, web extract, mcp, skills_hub, approval, and triage_specifier. The OAuth branch in resolve_provider_client only handled oauth_device_code and oauth_external, so providers with the custom auth_type="oauth_minimax" fell through to the catch-all warning:

WARNING agent.auxiliary_client: resolve_provider_client: unhandled
auth_type oauth_minimax for minimax-oauth

…and the title generator then emitted the misleading diagnostic:

Title generation failed: Provider 'minimax-oauth' is set in
config.yaml but no API key was found. Set the MINIMAX-OAUTH_API_KEY
environment variable, or switch to a different provider with
hermes model.

The env-var hint is wrong — MINIMAX-OAUTH_API_KEY is for the api_key variant of MiniMax, not the OAuth one. The actual credential is in ~/.hermes/auth.json and the main agent reads it fine via resolve_minimax_oauth_runtime_credentials; the auxiliary path just never asked.

The fix mirrors the existing xai-oauth branch (which was added with the same reasoning in ab2472e): a dedicated provider == "minimax-oauth" branch in resolve_provider_client that builds an AnthropicAuxiliaryClient against MiniMax's /anthropic endpoint. MiniMax's Anthropic-compatible endpoint is in
_ANTHROPIC_COMPAT_PROVIDERS (line 4740), so the right transport is the Anthropic Messages API wrapped via build_anthropic_client, not an OpenAI client.

Two small improvements over a minimal port:

1. as_token_provider=True — the OAuth access token is short-lived, so the resolver returns a zero-arg callable that mints a fresh token per request. Long aux sessions (compression in particular) no longer risk failing mid-call when the access token expires.

2. The new branch's comment block explains the user-visible symptom (silent re-routing to fallback + misleading "no API key" diagnostic) so the next person reading the resolver can see why the branch exists without re-deriving the bug.

Smoke-tested against a live minimax-oauth login in the .hermes/hermes-agent venv: title generation returns a real title in ~5s, no unhandled auth_type warnings, no no API key diagnostic. _build_minimax_oauth_aux_client returns an AnthropicAuxiliaryClient wrapping the real Anthropic client.

What does this PR do?

Related Issue

Fixes #

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

How to Test

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:

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

For New Skills

• This skill is broadly useful to most users (if bundled) — see Contributing Guide
• SKILL.md follows the standard format (frontmatter, trigger conditions, steps, pitfalls)
• No external dependencies that aren't already available (prefer stdlib, curl, existing Hermes tools)
• I've tested the skill end-to-end: hermes --toolsets skills -q "Use the X skill to do Y"

Screenshots / Logs

[alt-glitch]

Duplicate of open PR #36779 (same minimax-oauth routing fix in auxiliary_client.py for #36091/#21521). Multiple prior competing PRs: #22213/#25287/#27640/#30059. Suggest consolidating.