What does this PR do?

Adds a time-to-first-byte (TTFB) watchdog for the Codex Responses streaming
path so a connection that is accepted but never produces a byte is recovered
in seconds instead of being held for the full wall-clock stale timeout.

The problem. Against the chatgpt.com/backend-api/codex backend we hit an
intermittent failure mode where the endpoint accepts the TCP/TLS connection but
never emits a single stream event — the socket just hangs. It eventually
surfaces as a stale-call kill or httpx.RemoteProtocolError: peer closed connection without sending complete message body. It reproduces when probing
the backend directly and sequentially (no concurrency): a request hangs with
zero events and no HTTP status, while an immediate fresh reconnect succeeds
within a couple of seconds. So it appears to be backend-side, and a fast
reconnect is the effective recovery.

Why the existing guard isn't enough. interruptible_api_call supervises the
Codex stream with a wall-clock stale detector. That timeout has to stay high
(it also covers legitimate long reasoning generations), so a dead-on-arrival
connection is held for the whole window before the retry loop can reconnect —
many seconds to minutes of wasted wall time per stall.

The fix. While no stream event has arrived yet, apply a much shorter TTFB
cutoff and kill the connection so the retry loop reconnects promptly. Once any
event arrives the stream is healthy and only the existing wall-clock stale
timeout applies, so long generations are never interrupted. The "bytes flowing"
signal is set on any event (not just output-text deltas), so reasoning-only
and tool-call-only turns are not mistaken for a stall. Gated to the
codex_responses path; the chat_completions non-stream, Anthropic and Bedrock
branches have no first-event signal and are untouched. The raised TimeoutError
flows through the existing retry path unchanged.

Related Issue

No tracked issue. Related prior art (different mechanism): #22277 / #22278 target
eager fallback on stream-stall timeouts; this PR instead adds a first-byte
kill on the codex_responses supervisor so the same provider reconnects fast
on the no-first-byte case.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• agent/codex_runtime.py — stamp agent._codex_stream_last_event_ts on every
  Responses stream event so the supervisor can tell whether any byte has arrived.
• agent/chat_completion_helpers.py — TTFB watchdog in interruptible_api_call:
  before the first event, kill + retry once elapsed > HERMES_CODEX_TTFB_TIMEOUT_SECONDS
  (default 45, set 0 to disable); after the first event, behaviour is unchanged.
• tests/agent/test_codex_ttfb_watchdog.py — new regression tests.

How to Test

1. pytest tests/agent/test_codex_ttfb_watchdog.py -v — covers three cases:
   no-event stall is killed quickly with a retryable TimeoutError and a
   codex_ttfb_kill close reason; a stream that emits an event then runs past
   the cutoff is not killed; HERMES_CODEX_TTFB_TIMEOUT_SECONDS=0 disables it.
2. Regression: pytest tests/agent/test_non_stream_stale_timeout.py tests/run_agent/test_run_agent_codex_responses.py tests/run_agent/test_streaming.py tests/run_agent/test_interrupt_propagation.py tests/run_agent/test_openai_client_lifecycle.py tests/run_agent/test_codex_xai_oauth_recovery.py -v — all pass.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(codex): ...)
• I searched existing PRs for duplicates
• My PR contains only changes related to this fix
• I've run the affected test suites and they pass (see How to Test) — not the full suite
• I've added tests for my changes
• I've tested on my platform: Linux

Documentation & Housekeeping

• No new config keys (env-var-only knob, documented in code) — N/A for cli-config.yaml.example
• No architecture/workflow change — N/A for CONTRIBUTING.md/AGENTS.md
• Cross-platform: pure-Python timing/threading, no platform-specific calls
• No tool description/schema changes — N/A