centralize Responses retry policy

[rhan-oai]

Why

#23951 added remote compaction v2 retries, but it left the retry and WS -> HTTPS fallback behavior duplicated between normal Responses turns and compaction. This follow-up centralizes the common retry handling so future changes to fallback, retry delay, retry notifications, and retry sleep do not have to be kept in sync across both callsites.

What changed

• Added core/src/responses_retry.rs with a shared handler for retryable Responses stream errors.
• Reused that handler from normal turn sampling and remote compaction v2.
• Kept each callsite responsible for its retry budget: normal turns still use stream_max_retries, while compaction v2 still uses min(stream_max_retries, 2).
• Preserved caller-specific behavior around non-retryable errors, context-window errors, usage-limit errors, and compact-specific final failure logging.

The shared handler now owns:

• WS -> HTTPS fallback warning emission
• retry delay selection, including server-requested stream retry delay
• retry logging
• first-WebSocket-retry notification suppression
• Reconnecting... n/max stream-error notification
• sleeping before the next retry attempt

Verification

• cargo test -p codex-core remote_compact_v2
• cargo test -p codex-core websocket_fallback
• just fix -p codex-core

Did not run the full workspace test suite.