Hermes mislabels upstream 429 quota exhaustion as missing Codex credentials

Summary

When the primary provider (openai-codex via ChatGPT Plus/Pro OAuth) returns a 429 "usage limit" response (e.g. hit your usage limit. Try again at <reset_time>), Hermes gateway:

1. Logs WARNING gateway.run: Primary provider auth failed: No Codex credentials stored. Run \hermes auth` to authenticate.` — incorrect; credentials are valid.
2. Surfaces the same string to the user-facing chat response when no fallback_providers is configured, causing operator panic ("did our tokens leak / get revoked?").
3. Reports the failed credential in hermes auth list as device_code rate-limited (429) (Xh Ym left) — accurate, but disagrees with the chat-surface message.
4. When fallback_providers IS configured with an Ollama provider, logs Fallback provider resolved: openrouter model=<X> — labels the resolved provider as "openrouter" even though the config specifies provider: ollama and traffic correctly hits localhost:11434.

Reproduction

1. Configure openai-codex as primary with a ChatGPT Plus/Pro OAuth credential.
2. Exhaust the ChatGPT Codex usage quota (sustained agent workload + cron jobs).
3. Send any user message that triggers an inference call.
4. Observe gateway.log warning + Discord/Slack reply containing the misleading auth-error string.

Expected vs actual

Root cause hypothesis

The provider-error handler appears to flatten upstream 4xx/quota errors into a single "no credentials" branch, likely because the user-facing remediation has historically been "re-auth." For OAuth-backed plans, this remediation is wrong when the failure mode is a usage cap rather than missing/expired tokens.

The openrouter label on resolved fallback providers looks like an internal category label leaked into operator-facing logs.

Suggested fix

1. Separate provider-error classification from remediation copy. At minimum:
   • 401 / 403 → No Codex credentials stored. Run hermes auth.
   • 429 + body containing "usage limit" or retry-after header → Provider quota exhausted; reset at <time>. Surface to chat as a non-alarming degraded-mode notice when a fallback is configured.
   • 5xx → Provider error; retrying via fallback.
2. In gateway.run's Fallback provider resolved: log line, print the literal provider key from config instead of the resolved category.

Operator impact

Until #1 lands, every quota exhaustion event triggers operator panic and hermes auth re-runs that cannot succeed (token is fine; quota is not). Mitigation in place locally: 2-tier Ollama fallback chain swallows the impact on user-facing replies, so this is now observability-only severity.

Notes for upstream

Tested on Hermes 0.14.0 (2026.5.16) + Codex CLI 0.133.0 + ChatGPT Pro plan during a real quota outage window. Fleet of 13 profiles all reproduced the same error string verbatim. Full state captured locally if useful.