Support Responses WebSocket traffic through the Capsem MITM proxy

## Problem

Codex inside a Capsem VM currently cannot use the built-in OpenAI provider's Responses WebSocket transport through Capsem's MITM proxy.

Observed repro from a fresh installed-layout VM:

```text
codex doctor
...
✓ auth auth is provided by environment
auth env vars present OPENAI_API_KEY
⚠ websocket Responses WebSocket failed
endpoint wss://api.openai.com/v1/
handshake transport error http 400 Bad Request: Some("Capsem: WebSocket upgrades are not supported (GET /v1/responses)\n")
```

Running `codex exec` then fails with:

```text
ERROR: Capsem: WebSocket upgrades are not supported (GET /v1/responses)
```

This can look like "Codex cannot find the OpenAI key", but the key path is working: `OPENAI_API_KEY` is injected and Codex doctor reports env auth.

## Current workaround

Commit `e8e6ce6d` changed Capsem's generated in-VM Codex config to use a `capsem-openai` provider alias with:

```toml
model_provider = "capsem-openai"

[model_providers.capsem-openai]
name = "OpenAI via Capsem"
base_url = "https://api.openai.com/v1"
env_key = "OPENAI_API_KEY"
wire_api = "responses"
supports_websockets = false
```

That makes Codex use normal HTTPS streaming through Capsem, which already works with the existing MITM policy and telemetry path.

## Desired fix

Add first-class WebSocket upgrade support in the Capsem MITM proxy so model clients that prefer or require WebSockets can work without per-client transport overrides.

Key points to design/test:

- Accept and proxy HTTP/1.1 `Upgrade: websocket` through the MITM path.
- Preserve policy decisions before the upstream connection is established.
- Preserve telemetry for connection lifecycle, request metadata, close/error state, and provider attribution.
- Decide what model-call evidence can be captured from WebSocket frames, and fail closed or degrade explicitly if frame interpretation is unsupported.
- Add regression tests for `GET /v1/responses` WebSocket upgrade instead of the current intentional `400 websocket-not-supported` path.

## Acceptance criteria

- A fresh Capsem VM can run `codex doctor` with the built-in OpenAI provider without the WebSocket warning caused by Capsem.
- `codex exec` can use the built-in OpenAI provider through Capsem without requiring `supports_websockets = false`.
- Existing HTTP/SSE OpenAI, Anthropic, and Gemini paths remain covered and unaffected.
- Telemetry records WebSocket allow/deny/error outcomes clearly.