### Check for existing issues

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

### What happened?

When the `s3_v2` logging callback writes a request payload to S3, the object key (and the `Content-Disposition` download filename) is derived from the upstream provider's response id rather than the LiteLLM `request_id` that gets stored in the database.

For the native Anthropic Messages path (`call_type == anthropic_messages`, POST `/v1/messages`), the response carries Anthropic's own `msg_...` id. That `msg_...` id ends up in the S3 object name, while the `LiteLLM_SpendLogs.request_id` column for the same request resolves to `litellm_call_id`. The two identifiers diverge, so there is no way to take an S3 object name and look up its corresponding row by `request_id`.

The `msg_...` id is not stored in any dedicated DB column. It only appears inside the `LiteLLM_SpendLogs.response` JSON blob (`response->>'id'`), and only when `store_prompts_in_spend_logs` is enabled. With that setting off, the S3 filename id is unrecoverable from the database entirely.

## Root cause

The S3 object name is built from the standard logging payload id, which is th…