Expected Codex WebSocket fallback is logged as an error on every protected run

## Problem

Pentect intentionally rejects Codex Responses WebSocket upgrades with HTTP 426 so Codex retries over protected HTTP/SSE. With current Codex CLI 0.153.0, each otherwise successful protected run prints an ERROR-level failed-to-connect message before continuing.

## Confirmed behavior

Real Codex exec sessions through the current main-equivalent Pentect tree consistently showed:

ERROR ... responses_websocket: failed to connect to websocket: HTTP error: 426 Upgrade Required

The subsequent POST /responses path succeeded, the provider received handles, and tool restoration worked. This is expected fallback, not an actual failed session.

The Pentect behavior is explicit at crates/pentect-cli/src/openai_http_proxy.rs:356-369. For the built-in openai provider, CodexHttpRouting at main.rs:2814-2829 preserves that provider ID and sets only openai_base_url, intentionally relying on the 426 fallback. Custom providers get supports_websockets=false.

## Impact

- Every healthy Codex launch begins with a red ERROR that looks like protection or provider failure.
- Operators and support automation cannot distinguish this expected compatibility handshake from a real gateway error.
- The extra failed connection adds avoidable startup/turn latency and noise.
- Current-client drift can change fallback behavior without a focused release assertion.

## Acceptance criteria

- Prevent the WebSocket attempt when Codex offers a supported configuration signal, or otherwise make the expected fallback non-error and non-user-visible.
- Preserve the ability to resume the same Codex thread outside Pentect, which is why the built-in provider ID is currently retained.
- Never enable an uninspected WebSocket path merely to remove the warning.
- Add a real-current-Codex test asserting that a successful protected turn has no expected-fallback ERROR.
- Keep a protocol test proving any unexpected upgrade still fails closed and HTTP/SSE remains protected.
- Document unavoidable upstream noise if current Codex provides no safe suppression mechanism.

Related code already has a unit test for the 426 response; this issue is about the actual client UX and compatibility contract.

Start with crates/pentect-cli/src/openai_http_proxy.rs:356-369 and the CodexHttpRouting setup in main.rs:2814-2829, then inspect the existing unit test for the 426 response. Reproduce a protected Codex CLI 0.153.0 run and add a current-client test covering the successful-turn log output. Done means expected fallback noise is suppressed safely, HTTP/SSE remains protected, and an unexpected upgrade still fails closed.

Written by the indexing model from the issue text.