### What happened

When a client calls the proxy's `/v1/responses` for a non-OpenAI backend (so LiteLLM bridges Responses→Chat), the returned `response.id` is an encrypted base64 blob of the form `resp_<base64url>=` (the "encrypted content affinity" id encoding `model_id` etc.).

LiteLLM's `langfuse` success-callback then logs this id as the observation/generation id. LangFuse v3 uses the observation id **verbatim as the S3/MinIO object key** (`<projectId>/observation/<id>/<uuid>.json`). The base64 padding/charset is rejected by MinIO:

``` XMinioInvalidObjectName: Object name contains unsupported characters ```

The blob upload aborts at LangFuse's ingestion (web) stage, nothing is enqueued, and the trace silently never appears. The LiteLLM callback itself returns 200, so it looks like tracing is just broken with no error surfaced to the caller.

### Why this matters

`resp_…=` is technically a valid OpenAI id, but using base64 **padding (`=`)** (and base64url charset) in an id that downstream logging integrations route into object-storage keys is unsafe. AWS S3 tolerates `=`; MinIO (a first-class, very common self-hosted S3 target) does not. Any LiteLLM user pairing the Responses…