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

[Anmol Jaiswal (anmolg1997)]

Fixes #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;....

[ccurme (ccurme)]

Closing pending discussion on the issue.

[codspeed-hq]

Merging this PR will not alter performance

✅ 13 untouched benchmarks
⏩ 2 skipped benchmarks¹

---

_{Comparing anmolg1997:fix/openai-file-block-mime-type (58f0d26) with master (dfb8a61)²}

Footnotes

1. 2 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on master (666dc16) during the generation of this report, so dfb8a61 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[Anmol Jaiswal (anmolg1997)]

Pushed an update following the discussion on #36939.

Kept the original mime_type fix in _convert_openai_format_to_data_block, and added a small guard in convert_to_openai_data_block(api="chat/completions") that raises a clear ValueError for non-PDF base64 file blocks instead of letting OpenAI return a raw 400. Tests cover both behaviors. Responses API path is unchanged.