fix: core: recognize OAS 3.1 contentMediaType for binary classification

[erichasinternet]

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  All three ran clean; no incidental sample or doc diff.
• File the PR against the correct branch: master (additive, non-breaking).
• If your PR solves a reported issue, reference it using GitHub's linking syntax (fixes [REQ] Add support for contentMediaType/contentMediaEncoding to align with OAS 3.1 #23095 below).
• If your PR is targeting a particular programming language, @mention the technical committee members. N/A — core change; every language target benefits via the shared classifier.

Description

Problem. OpenAPI 3.1 declares binary string fields with JSON Schema 2020-12's contentMediaType keyword:

type: string
contentMediaType: application/octet-stream

ModelUtils.isBinarySchema() only recognized the 3.0 idiom (format: binary), so 3.1 specs (e.g. anything emitted by FastAPI ≥0.99) failed to classify file fields. Downstream, parameters were routed through _form_params (plain text) rather than _files (binary multipart).

Change. Extend isBinarySchema() to also match contentMediaType: application/octet-stream. format: binary remains valid in 3.1 (deprecated but not removed) and continues to match. The fix is additive at the single chokepoint used by twelve isFile = true sites in DefaultCodegen and eleven other language targets, so every consumer picks up correct 3.1 handling without target-specific changes.

Tests. testIsBinarySchemaOAS30FormatBinary guards the existing 3.0 path; testIsBinarySchemaOAS31ContentMediaType covers the new 3.1 path and asserts a non-octet-stream contentMediaType (e.g. image/png) does not false-positive. Paired 3_0/binary-schema.yaml and 3_1/binary-schema.yaml fixtures show the same upload body in both dialects.

Validation. Full ModelUtilsTest passes (38 cases). bin/generate-samples.sh ./bin/configs/*.yaml and bin/utils/export_docs_generators.sh both produce zero diff — no existing spec uses contentMediaType.

fixes #23095
refs #13083, #9083