Document multipart serializer mislabels MIME and emits duplicate file parts

Start in src/main/java/com/razorpay/ApiUtils.java, reading getMediaType and fileRequestBody. Reproduce the serializer output for the PNG and PDF cases, then add or update a multipart wire test covering MIME values, unknown extensions, and file-part cardinality. Done means one binary file part uses the documented MIME type and ordinary fields do not duplicate file.

Summary

The Java SDK's document multipart serializer has two independent wire-format defects in one request:

1. Runtime JPG/JPEG/PNG/JFIF paths are compared with ==, so a normal proof.png path is classified as image/pdf. PDF also falls through to the non-standard image/pdf rather than documented application/pdf.
2. The serializer adds file once as a binary part, then iterates the complete request object and adds the same file key again as a text pathname.

Affected commit: ad9ab7b6e6f045b782dfd7608da04de9f930ad97

Reproduction

I executed the pinned official SDK serializer through reflection and wrote the resulting RequestBody to an Okio buffer:

{
  "png_media_type": "image/pdf",
  "file_parts": 2
}

Input shape:

{
  "file": "/tmp/proof.png",
  "purpose": "dispute_evidence"
}

Relevant source is src/main/java/com/razorpay/ApiUtils.java:

• getMediaType compares the substring extension using == and |.
• fileRequestBody adds the binary file part.
• Its following loop adds every request key, including file, again as a text part.

The Document API documents a singular file field and MIME values image/jpg, image/jpeg, image/png, and application/pdf.

Expected

• One binary multipart part named file.
• Correct documented MIME type for the selected file.
• Unknown extensions rejected rather than classified as PDF.

Suggested fix

• Map lower-cased extensions with .equals/.equalsIgnoreCase to their exact MIME types.
• Exclude file from the ordinary form-field loop.
• Add a multipart wire snapshot test asserting both MIME and field cardinality.

No credentials or provider-side mutation are required to reproduce this SDK serialization defect.