fix(tui): fall back on primary AuthError during agent creation

[VrtxOmega]

Fixes #43588

Problem

When model.provider is an OAuth provider with invalid/revoked credentials (e.g. xai-oauth) but fallback_providers is configured, the CLI and messaging gateway already fall through to the fallback chain. Desktop/TUI hard-errored on the first message because _make_agent() called resolve_runtime_provider() directly with no AuthError → fallback handling.

Fix

Add _resolve_runtime_with_auth_fallback() in tui_gateway/server.py, mirroring gateway/run.py::_resolve_runtime_agent_kwargs and CLI _ensure_runtime_credentials. _make_agent() now tries the configured fallback chain on primary AuthError and switches to the fallback model when resolution succeeds.

Tests

• test_make_agent_falls_back_on_primary_auth_error — dead xAI OAuth → openrouter fallback
• test_make_agent_auth_error_without_fallback_raises — no fallback configured still surfaces error

.venv/bin/python3 -m pytest tests/test_tui_gateway_server.py::test_make_agent_falls_back_on_primary_auth_error tests/test_tui_gateway_server.py::test_make_agent_auth_error_without_fallback_raises tests/gateway/test_auth_fallback.py -q

[liuhao1024]

Two test assertions will fail when CI runs:

1. captured["api_key"] mismatch in both tests

fake_resolve returns "api_key": "***", but both test_make_agent_falls_back_on_primary_auth_error and test_make_agent_auth_fallback_skips_stale_session_overrides assert:

assert captured["api_key"] == "fallback-key"

The mock resolution for requested="openrouter" returns "***", so this assertion should be:

assert captured["api_key"] == "***"

2. captured["fallback_model"] type mismatch

_resolve_runtime_with_auth_fallback returns (runtime, fb_model) where fb_model = entry.get("model") — a string like "meta-llama/llama-4-maverick". But the test asserts:

assert captured["fallback_model"] == fallback_chain

where fallback_chain is a list of dicts. Unless _make_agent re-serializes the chain into the fallback_model kwarg (which the diff doesn't show), this would also fail.

[VrtxOmega]

Thanks @liuhao1024 — took another pass on the assertions:

1. api_key — fake_resolve in these tests returns "fallback-key" (not "***"; that's the gateway test style). Assertions now derive from a shared fallback_runtime dict so they stay tied to the mock output.

2. fallback_model — _make_agent() still passes fallback_model=_load_fallback_model() (the chain list) into AIAgent. The helper's second return value (fb_model string) only updates the active model= kwarg. Added test_resolve_runtime_with_auth_fallback_returns_fallback_entry_model to document the split.

.venv/bin/python3 -m pytest \
  tests/test_tui_gateway_server.py::test_resolve_runtime_with_auth_fallback_returns_fallback_entry_model \
  tests/test_tui_gateway_server.py::test_make_agent_falls_back_on_primary_auth_error \
  tests/test_tui_gateway_server.py::test_make_agent_auth_fallback_skips_stale_session_overrides \
  tests/gateway/test_auth_fallback.py -q

7 passed locally.

[teknium1]

Thanks for the focused regression coverage. Current main contains an overlapping init-time AuthError fallback from f44415e71a (tui_gateway/server.py:4444), so this cannot be cleanly cherry-picked. However, it does not fully implement this PR's model-selection behavior: it resolves a fallback using only requested at tui_gateway/server.py:4469, then still constructs AIAgent(model=model) at tui_gateway/server.py:4604. The current integration test explicitly preserves the primary gpt-5.5 model despite configuring deepseek-v4-pro as the fallback (tests/test_tui_gateway_server.py:8839-8856).

Problems

• The current implementation fixes provider credential resolution but leaves the configured fallback model unused during agent construction.

Suggested changes

• Salvage the fallback-entry model propagation and stale-session-override protection into the existing _resolve_runtime_with_fallback / _make_agent structure.
• Update the integration assertion to require both fallback provider and fallback model.

Automated hermes-sweeper review.

[teknium1]

Merged via PR #65682 with you credited as commit author (998e35313). Your provider/model fallback pairing landed earlier via PR #65656's salvage of #65264 — but the key_env API-key resolution in your TUI fix was a real gap that fix didn't cover, so we extracted it, centralized it in hermes_cli/fallback_config.resolve_entry_api_key(), and applied it to all four fallback surfaces (TUI, cron, gateway, CLI setup). Your original branch predated the fallback restructuring so a direct cherry-pick wasn't possible; the reapplied commit carries your authorship. Thanks for spotting both halves of this!