fix(oneshot): consult fallback_providers at resolution time

[Enough1122]

Fixes #81209

Root cause

The gateway has _try_resolve_fallback_provider (gateway/run.py:2502) which resolves a fallback provider at resolution time — before AIAgent is constructed. A gateway turn therefore survives a primary-provider quota window when fallback_providers is configured and healthy.

The CLI/oneshot lane had no equivalent. hermes_cli/oneshot.py called resolve_runtime_provider(...) bare at line 385. When the credential pool is exhausted, that call raises before AIAgent is constructed, so the fallback_model=_fb wiring at oneshot.py:436 — which handles mid-session failures — never gets a chance. The result matches the issue's reproduction:

$ hermes -z "Health check: reply pong."
hermes -z: agent failed: Codex provider quota exhausted (429); retry after 39750s.

The docs ("Where Fallback Works: CLI sessions ✔") read as full coverage, but in practice the CLI was only covered for failures that occur after the session starts. Headless deployments are hit hardest: cron jobs and queue workers that shell out to hermes -z died for the entire quota window even with a healthy fallback configured.

Fix

New helper _resolve_runtime_with_fallback in hermes_cli/oneshot.py, called from _run_agent in place of the bare resolve_runtime_provider call:

1. Try the primary provider as before.
2. On failure, walk get_fallback_chain(cfg) in order — the same single source of truth the gateway uses — resolving each entry with the same resolve_entry_api_key semantics.
3. On total failure, re-raise the primary error: it names the operator's configured primary provider, which is what needs fixing first (a fallback entry's failure is not the operator's configured-first provider).

The existing fallback_model=_fb wiring is untouched and still handles mid-session failures; this change only adds the resolution-time lane the gateway already had.

Regression tests

5 tests in tests/hermes_cli/test_oneshot_fallback.py:

1. test_primary_success_short_circuits — primary success must not touch fallback entries.
2. test_primary_quota_failure_invokes_fallback — the issue's scenario: 429 → fallback entry resolves → agent proceeds.
3. test_primary_failure_no_fallback_chain_returns_primary_error — no chain configured: primary error surfaces unchanged.
4. test_all_fallbacks_exhausted_returns_primary_error — primary + every entry fails: primary error wins.
5. test_second_fallback_succeeds_when_first_also_fails — chain walk continues past a failed entry.

All 5 are RED on pre-fix code (helper does not exist → AttributeError) and GREEN after. Existing test_oneshot_usage_file.py (3 tests) continues to pass.

Scope

One new helper + one call-site change in oneshot.py; no refactor, no API surface change. The gateway's _try_resolve_fallback_provider is left as-is (the oneshot path needs the cfg-driven semantics this helper has; reusing the gateway function would import the whole gateway config loader).

[Enough1122]

Fix follow-up: the original PR's helper docstring promised to stamp the fallback entry's model onto the returned runtime dict (same as the gateway does at run.py:2540), but never actually did. AIAgent received the primary model, so a oneshot that fell back to e.g. Anthropic credentials would still be asked for the primary provider's model.

This follow-up:

• Passes target_model=entry.get('model') to resolve_runtime_provider for each fallback entry.
• Stamps runtime['model'] = entry['model'] on the returned dict so AIAgent sees the fallback's model.
• Honors runtime.get('model') in _run_agent (falls back to effective_model on primary success).
• Adds a regression test asserting the fallback model is injected.

6/6 tests pass locally.