fix(openai): model-aware api_mode for direct api.openai.com (GPT-4.1/4o use Chat Completions)

[professorpalmer]

Problem

Direct OpenAI access (the built-in openai-api provider, and any
api.openai.com base URL) is hardcoded to the Responses API
(codex_responses) for every model. The Responses API rejects
non-reasoning chat models, so they're currently unusable via Hermes:

• gpt-4.1, gpt-4o → HTTP 400 "Encrypted content is not supported with this model" (this is the include: ["reasoning.encrypted_content"] parameter the Responses path sends — see [Bug]: [Bug]: Hermes v0.13.0 sends unsupported include parameter causing "Encrypted content is not supported with this model" error with OpenAI GPT-4o #23450)
• other GPT-4.x / GPT-3.5 chat models → same class of failure

Reasoning families (GPT-5.x, o1/o3/o4, codex) genuinely require the
Responses API, so a single transport per host can't be correct — it has
to be chosen per model.

Repro

hermes chat -q "hi" -Q --provider openai-api -m gpt-4.1 --source tool --max-turns 2
# → 400 "Encrypted content is not supported with this model"

Fix

Hermes already solves this exact problem per-model for other providers —
azure_foundry_model_api_mode (Azure Foundry) and copilot_model_api_mode
(Copilot) both return the Responses API only for GPT-5+/o-series and Chat
Completions otherwise. This PR gives the direct OpenAI path the same
treatment:

• Add openai_model_api_mode(model) in hermes_cli/models.py. It reuses the
  existing _AZURE_FOUNDRY_RESPONSES_PREFIXES set (Azure Foundry hosts the
  same OpenAI families, so the Responses-only prefixes are identical):
  reasoning families → codex_responses, chat families → chat_completions,
  unknown/empty → None.
• Thread the effective model through the two api_mode-governing helpers and
  their OpenAI-resolving callers:
  • runtime_provider._detect_api_mode_for_url(base_url, model) — pool,
    explicit, env-key, and openrouter resolution paths.
  • providers.determine_api_mode(provider, base_url, model) — used by the
    /model switch path in model_switch.py.

Behavior

model	before	after
gpt-4.1, gpt-4o, gpt-4-turbo, gpt-3.5*	codex_responses (400)	chat_completions ✅
gpt-5, gpt-5.5, o1/o3/o4, codex*	codex_responses	codex_responses (unchanged)
unknown / no model	codex_responses	codex_responses (unchanged)

The unknown-model case preserves the historical Responses-API default, so
the gpt-5.x family Hermes ships as the openai-api default keeps working
exactly as before. An explicit model.api_mode / custom-provider override
still wins.

Note: o4-mini's separate "organization must be verified to generate
reasoning summaries" error is an OpenAI account-level setting, not a
transport bug — o4-mini correctly stays on the Responses API here.

Tests

python -m pytest \
  tests/hermes_cli/test_detect_api_mode_for_url.py \
  tests/hermes_cli/test_determine_api_mode_hostname.py \
  tests/hermes_cli/test_api_key_providers.py \
  tests/hermes_cli/test_runtime_provider_resolution.py \
  tests/hermes_cli/test_user_providers_model_switch.py \
  tests/cli/test_cli_provider_resolution.py -q
# 387 passed

New coverage: openai_model_api_mode units, model-aware
_detect_api_mode_for_url / determine_api_mode, and an end-to-end
resolve_runtime_provider(requested="openai-api", target_model=…) test
asserting gpt-4.1 → chat_completions while gpt-5.5 / o4-mini stay
codex_responses.

Fixes #23450

[alt-glitch]

Related: competing fixes for #23450 (Responses-API "Encrypted content is not supported with this model"). This PR adds a model-aware api_mode for the direct OpenAI path via a new openai_model_api_mode() helper threaded through runtime_provider/providers/model_switch. Other open PRs attack the same bug from different layers: #23460 and #24234 strip the unsupported include parameter at the Chat Completions transport, and #23734 gates the codex_responses upgrade at agent init. Same goal, different mechanism — flagged so reviewers can compare the approaches and pick one.

[teknium1]

Thanks for tracing the transport decision through the runtime resolver; the model-aware direction addresses a real current-main issue (hermes_cli/runtime_provider.py:126).

Problems

• In 724abf74b53d (hermes_cli/models.py:3299 in the PR diff), the final fallback returns chat_completions for every nonempty unrecognized ID. That conflicts with the PR's documented unknown-model behavior and changes the historical Responses fallback for future/unrecognized model families.
• hermes_cli/cli_agent_setup_mixin.py:41-45 still calls resolve_runtime_provider() without target_model. The one-shot path passes it (hermes_cli/oneshot.py:375-379), but the interactive setup path can classify from model.default rather than the active selected model.

Suggested changes

• Return None for unrecognized nonempty model IDs and explicitly identify the GPT-3.5/GPT-4 chat families.
• Thread the effective CLI model into the setup resolver and add a regression where it differs from model.default.

Automated hermes-sweeper review.

[teknium1]

This fallback classifies every nonempty unknown ID as Chat Completions, despite the documented unknown-model behavior preserving the Responses default. Please return None unless this is a recognized GPT-3.5/GPT-4 chat family; otherwise a future reasoning model such as gpt-6-preview is silently downgraded.