### Check for existing issues

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

### What happened?

When calling the proxy's `/v1/responses` endpoint, the Langfuse success-callback ignores `metadata["trace_id"]` and instead uses `metadata["session_id"]` as the actual Langfuse trace ID. It also fails to populate the trace-level `userId`, `sessionId`, and `metadata` fields — they're left empty even though the correct values are present in the request metadata and are visible (only) inside each observation's `requester_metadata`.

This means: 1. A caller that sets an explicit `metadata["trace_id"]` (e.g. to correlate a client-generated ID, such as a per-message UUID, with a Langfuse trace) gets a **different** trace ID than the one they specified — the trace actually lands at `metadata["session_id"]`. Any client-side reference to the trace by its intended `trace_id` 404s. 2. Every `/v1/responses` call that shares the same `session_id` collapses into a single Langfuse trace (one trace per session, not one per call), with trace-level fields overwritten by whichever observation was ingested last. 3. The trace object itself never gets `userId`/`sess…