Fall back gracefully on mid-stream Codex WebSocket failure

[amondnet]

Summary

Handle a Codex WebSocket failure that occurs mid-stream (after the first token) by degrading gracefully instead of erroring. Today a WS failure before streaming falls back to HTTP transparently, but a failure mid-stream surfaces as an error SSE event to the client.

Why

The pre-stream fallback already proves the HTTP path is a valid backstop. A socket that drops mid-turn (idle eviction race, backend hiccup, network blip) currently turns a recoverable transport failure into a user-visible error, even though the request could be retried over HTTP (or the WS reconnected and continued via previous_response_id). This is the one WS failure mode that isn't yet covered.

See docs/comparison.md §6 item C.

Tasks

• Detect mid-stream WS failure distinctly from a normal terminal event.
• Decide the safe recovery: (a) reconnect + continue via previous_response_id when the turn is resumable, or (b) restart the turn over HTTP. Note that tokens already emitted to the client constrain (b) — spec out the correct behavior (e.g. only fall back if nothing was streamed yet, else surface a clean error).
• Invalidate the pooled connection on any mid-stream failure (confirm invalidate_pool_key is hit on this path).
• Add tests for mid-stream drop → recovery/clean-error.

Evidence

• src/adapters/responses.rs:92-135 (pre-stream fallback; mid-stream surfaces as error SSE at :554)
• src/adapters/codex_ws.rs:110-112 (pool invalidation on error)

Related

• Comparison: docs/comparison.md
• Sibling WS items: live-probe normalization, speculative prewarm