fix(core): use parsed mime_type for base64 file blocks in openai translator

[LennyMalcolm0]

Fixes langchain-ai#36939.

The file branch of _convert_openai_format_to_data_block hard-codes mime_type="application/pdf", while the image branch right above it uses parsed["mime_type"] from the data URI. So a CSV sent via the OpenAI file block shape comes out with mime_type="application/pdf" in the v1 content block.

One-line change to read it off the parsed data URI, same as the image branch. _parse_data_uri returns None when the mime_type is missing, so parsed["mime_type"] is always set inside this branch.

Test added with a CSV and a text/plain data URI. Existing tests still pass since they use data:application/pdf;....

---

Cloned from langchain-ai#36940 for DevAsign stress testing.

[devasign-test-app]

AI review: all acceptance criteria met

The pull request successfully addresses the issue where the MIME type for base64 file blocks was hardcoded to 'application/pdf'. By extracting the MIME type from the parsed data URI, it now correctly supports non-PDF file types like CSV and plain text. All acceptance criteria are fully met, and appropriate unit tests have been added to verify the changes.

Acceptance criteria

Met

• The OpenAI block translator must extract the mime_type for base64 file blocks from the parsed data URI instead of hardcoding it to 'application/pdf'.
• Base64 file blocks with non-PDF mime types (such as text/csv or text/plain) must be converted to v1 content blocks with their respective parsed mime_type.
• Existing file blocks with application/pdf data URIs must continue to be converted with mime_type set to 'application/pdf'.
• A unit test must be added to verify that a file block with a non-PDF data URI (e.g., CSV or text/plain) is correctly converted to a v1 content block with the correct parsed mime_type.

Suggestions

Nitpicks

• Add explicit check for missing mime_type in convert_to_openai_data_block (libs/core/langchain_core/messages/block_translators/openai.py)
  Currently, if mime_type is missing from the block, a KeyError is raised when constructing the data URI for the responses API, or a less clear ValueError is raised for chat completions. Adding an explicit check similar to the image block translator would improve error clarity.