fix(models): pass file metadata tuple to Azure for PDF uploads

[SHAI-nikhil-chaudhary]

Description

Fixes #6539.

When using inline PDF attachments with Azure deployments (azure/<deployment>), litellm.acreate_file was receiving only anonymous raw bytes. Azure requires strict file metadata (filename and MIME type) for context stuffing, leading to an invalid_request_error rejecting the upload with an unsupported MIME type of None.

This PR updates the file argument passed to litellm.acreate_file for _FILE_ID_REQUIRED_PROVIDERS to use a standard HTTP multipart tuple: (filename, data, mime_type).

Changes Made

• Added import mimetypes to dynamically generate a fallback filename (e.g., document.pdf) based on the extracted mime_type.
• Updated the file payload in litellm.acreate_file to pass the tuple format expected by the underlying API clients, preserving metadata during upload.

Testing

Successfully tested using the network-free reproduction script provided in the original issue. The payload properly formats as ('document.pdf', b'%PDF-1.4\n', 'application/pdf') instead of b'%PDF-1.4\n'.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[SHAI-nikhil-chaudhary]

Hi @GWeale @wuliang229 , just wanted to follow up on this PR and check if you’ve had a chance to review it. I’d be happy to make any changes or address any feedback needed.
Thanks for your time!

[SHAI-nikhil-chaudhary]

Hi @ross-p @joefernandez @sanketpatil06 @llalitkumarrr @GWeale @wuliang229 , just wanted to follow up on this PR and check if you’ve had a chance to review it. I’d be happy to make any changes or address any feedback needed.
Thanks for your time!