### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

When LiteLLM Proxy handles a native `POST /v1/responses` request for an OpenAI provider, a top-level `client_metadata` field is silently removed before the request is sent upstream.

This also happens when the deployment explicitly configures:

```yaml allowed_openai_params: - client_metadata ```

The incoming request contains:

```json { "model": "repro-responses", "input": "ping", "stream": false, "client_metadata": { "probe": "keep-me" } } ```

But the upstream request captured after LiteLLM no longer contains `client_metadata`:

```json { "model": "repro-responses", "input": "ping", "stream": false } ```

This is the native OpenAI Responses API path. `use_chat_completions_api` is not enabled, so this is not a Responses-to-Chat-Completions translation issue.

For OpenAI-compatible upstreams that require `client_metadata` for agent/subagent request context, direct requests succeed, while requests routed through LiteLLM fail with an opaque upstream error such as:

```text litellm.BadGatewayError: OpenAIException - {"error…