feat: support proxy-aware OpenAI Responses WebSocket connections

- [x] I have looked for existing issues (including closed) about this

## Feature Request

Allow the OpenAI Responses WebSocket session to connect through an HTTP proxy, or expose a public connection/transport hook that lets callers supply a proxy-aware WebSocket connection.

Today `ResponsesWebSocketSessionBuilder` retains a `ResponsesCompletionModel`, but `connect_with_timeouts` uses the model client only for `base_url()` and `headers()`. The actual socket is opened with `tokio_tungstenite::connect_async(request)`, so a custom HTTP backend supplied through `ClientBuilder::http_client(...)` does not participate in the WebSocket connection.

### Motivation

Applications commonly use one configured outbound proxy for provider model discovery, HTTP/SSE completion calls, OAuth/MCP traffic, and WebSocket calls. Rig's generic client API supports a custom HTTP backend for normal requests, but the Responses WebSocket path opens a direct TCP/TLS connection to the provider.

For `wss://`, using an HTTP proxy requires establishing a `CONNECT` tunnel to the target, then performing TLS and the WebSocket upgrade inside that tunnel. Because the current builder exposes only connect and event timeouts, downstream callers cannot provide a proxy URL, connector, or pre-established stream without reimplementing Rig's Responses WebSocket session behavior.

This makes proxy behavior inconsistent across transports and can prevent WebSocket mode from working in networks where direct outbound connections are unavailable.

### Proposal

Add a public, non-breaking connection customization point to `ResponsesWebSocketSessionBuilder`.

Possible shapes include:

- proxy configuration supported by Rig's default native connector;
- a caller-supplied WebSocket connector or connection factory;
- a caller-supplied preconnected async stream used for the TLS/WebSocket handshake.

The exact API can follow Rig's generic HTTP client and WASM design, but should:

- keep the current direct `connect_async` behavior as the default;
- support HTTP `CONNECT` proxies for `wss://`;
- preserve request headers, connect timeout, event timeout, TLS validation, close behavior, and provider error mapping;
- avoid making native proxy dependencies mandatory for WASM consumers;
- allow applications to use the same effective proxy policy for HTTP/SSE and Responses WebSocket transports;
- include tests proving that a WebSocket session can be established through a local proxy/tunnel and that the default direct path remains unchanged.

### Alternatives

- Downstream applications can disable WebSocket mode and fall back to HTTP/SSE when a proxy is configured, but this loses WebSocket-specific latency and session behavior.
- Applications can fork or duplicate the Responses WebSocket session and manually perform `CONNECT`, TLS, and WebSocket setup, but that duplicates Rig's timeout, state, error, and protocol handling and must be removed after upstream support lands.
- Reading `HTTP_PROXY` or `HTTPS_PROXY` implicitly inside Rig would help some cases, but it is less explicit and testable, and does not cover applications with runtime or per-client proxy configuration.

The issue is about modifying `ResponsesWebSocketSessionBuilder` in the rig codebase. Start by locating the builder and its `connect_with_timeouts` method, which currently uses `tokio_tungstenite::connect_async`. Research how to integrate proxy support, likely via a custom connector or exposing a configuration point. Testing will involve setting up a local proxy and verifying WebSocket connections work through it.

Vom Indexierungsmodell aus dem Issue-Text verfasst.