#33448 [Bug]: Responses WebSocket drops deployment-level default request parameters
## Bug
Responses WebSocket mode does not apply deployment-level default request parameters when forwarding a `response.create` frame to a native provider WebSocket.
A router deployment configured with `reasoning_effort: high` selects the correct deployment, but because the client frame omits `reasoning`, the provider receives its default (`medium`) and rejects GPT-5 Pro, which only permits `high`. The equivalent HTTP Responses request succeeds because router deployment defaults are merged into the request.
## Reproduction
Configure a proxy model with a deployment-level default:
```yaml model_list: - model_name: gpt-5-pro litellm_params: model: azure/gpt-5-pro api_base: os.environ/AZURE_API_BASE api_key: os.environ/AZURE_API_KEY reasoning_effort: high ```
Connect to the Responses WebSocket endpoint and send a normal frame without an explicit `reasoning` block:
```json { "type": "response.create", "model": "gpt-5-pro", "store": false, "input": "Say hello", "tools": [] } ```
The proxy selects the configured deployment, but the provider returns:
```json { "type": "error", "status": 400, "error": { "type": "invalid_request_error…