Fix custom provider API mode detection for OpenAI-compatible endpoints

[luoxiao6645]

Summary

• Prevent stale model.api_mode from leaking into custom and explicit API-key provider runtimes
• Tighten direct OpenAI detection so only the api.openai.com host is treated as native OpenAI, not proxy URLs that merely contain it in the path
• Align main-agent runtime resolution, provider fallback helpers, and auxiliary clients on the same API-mode detection rules

Fixes #9064

Problem

Custom OpenAI-compatible endpoints could be misclassified as codex_responses instead of chat_completions.

That caused Hermes to send Responses-style payloads to chat-completions backends, which broke request validation and produced errors such as:

Key: 'GptVParam.Messages' Error:Field validation for 'Messages' failed on the 'required' tag

Fix

• Add provider-family guards before honoring persisted model.api_mode
• Replace broad api.openai.com substring checks with hostname-based detection
• Keep proxy URLs that only include api.openai.com in the path on the chat_completions path
• Apply the same detection logic across runtime provider resolution, main agent request routing, fallback helpers, and auxiliary clients

Regression Coverage

• Stale api_mode does not leak into custom endpoints
• Stale api_mode does not leak into explicit API-key providers
• Proxy URLs containing api.openai.com in the path are not treated as native OpenAI
• Auxiliary client wrapping and token-param selection follow the corrected detection logic

Validation

venv\Scripts\python -m pytest -n 0 tests\agent\test_auxiliary_client.py
venv\Scripts\python -m pytest -n 0 tests\hermes_cli\test_runtime_provider_resolution.py
venv\Scripts\python -m pytest -n 0 tests\run_agent\test_strict_api_validation.py
venv\Scripts\python -m pytest -n 0 tests\agent\test_minimax_provider.p

[teknium1]

Thanks for the detailed cross-path analysis. The linked plain-custom failure is already covered on current main by 0e4c879a3 (hermes_cli/runtime_provider.py:136-155), but there is still a narrow hostname-hardening gap worth salvaging.

Problems

• hermes_cli/providers.py:551 still uses a broad "api.openai.com" in url_lower check for known providers. This reaches live model-switch setup through agent/agent_runtime_helpers.py:1752-1756.
• The added proxy test uses "totally-unknown", so it exercises the already hostname-safe unknown-provider branch (hermes_cli/providers.py:559-568), not the known-provider branch this PR changes.
• Current main already centralizes hostname parsing in utils.base_url_hostname() (hermes_cli/runtime_provider.py:117); the PR's duplicated local helpers should not be carried forward.

Suggested changes

• Salvage the remaining providers.py branch with base_url_hostname(base_url) == "api.openai.com".
• Add the regression using a known provider and a proxy path containing api.openai.com.

Automated hermes-sweeper review.

[teknium1]

This uses an unknown provider, which already takes the hostname-safe fallback branch. Please exercise a known provider (for example openrouter) so the test covers the get_provider(provider) is not None branch that still has the substring check on current main.