fix(oas31): render file picker for array items with contentMediaType

[Alixmixx]

fix(oas31): render file picker for array items with contentMediaType

Description

JsonSchema_array has a hardcoded isArrayItemFile check that only looks at
format: binary to decide whether to render file pickers. It never checks
contentMediaType, so array items like:

{ "type": "string", "contentMediaType": "application/octet-stream" }

end up rendering as plain text inputs instead of "Choose File" buttons.

The single-file case already handles this correctly in oas31/oas3-extensions/fn.js.
This PR brings the array case in line with the same logic.

Motivation and Context

Fixes #10825

FastAPI 0.129.1+ stopped emitting format: binary for UploadFile fields,
switching to contentMediaType: application/octet-stream to follow the OAS 3.1
/ JSON Schema 2020-12 spec. This broke List[UploadFile] endpoints and I saw
text inputs instead of file pickers in the try-it-out UI.

How Has This Been Tested?

• Added a fixture endpoint (multipart/form-data with array items carrying contentMediaType)
• Added a Cypress e2e test: click "Add item", assert the input has type="file"
• Manually tested against a FastAPI 0.135 app

Screenshots (if appropriate)

Before: text input

After: file picker

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.