OpenAPI 3.1 application/zip responses lower to void without legacy format: binary #17415

Fern treats a standards-correct OpenAPI 3.1 raw ZIP response as having no response body unless the schema retains the OpenAPI 3.0 type: string / format: binary hints.

Environment:

• fern-api 5.95.1 (also reproduced on 5.89.0)
• fern-typescript-sdk 3.85.2

openapi: 3.1.1
info:
  title: Binary response repro
  version: 1.0.0
paths:
  /archive:
    get:
      operationId: downloadArchive
      responses:
        "200":
          description: Raw ZIP
          content:
            application/zip:
              schema:
                contentMediaType: application/zip

Actual generated signature:

public downloadArchive(...): core.HttpResponsePromise<void>

Expected: a file/binary response (core.HttpResponsePromise<core.BinaryResponse> in TypeScript), with binary response handling in the generated transport.

OpenAPI 3.1 models raw binary outside the JSON data model: type is omitted, and contentMediaType may be omitted when the Media Type Object key already supplies it. Its 3.0 migration guidance maps type: string + format: binary to contentMediaType or an empty schema, so requiring the old hints defeats a standards-correct 3.1 migration: https://spec.openapis.org/oas/v3.1.1.html#working-with-binary-data

Current workaround:

schema:
  type: string
  format: binary
  contentMediaType: application/zip

That restores the binary return. Under the same configuration, application/pdf is already inferred as binary without the legacy hints, while application/zip is not. A referenced schema containing only contentMediaType: application/zip is also exported as unknown rather than a binary/bytes type.

Suggested acceptance: infer raw binary from the response Media Type Object / 3.1 contentMediaType, without requiring type: string or format: binary; preserve a binary representation for referenced raw-binary schemas when Fern emits them publicly.