Align TypeScript multipart file array handling

[hwisu]

Summary

• Align multipart form file array handling across typescript-fetch, typescript-axios, and typescript-inversify.
• Detect binary array form params from parameter.items, not only from the array parameter's own dataFormat.
• Share the binary form-array predicate in AbstractTypeScriptClientCodegen so the TypeScript client family uses the same rule.
• Add regression coverage for typescript-fetch, typescript-axios, and typescript-inversify generated output.

Root Cause

For type: array with items: { type: string, format: binary }, the binary/file metadata is attached to the item schema. The affected TypeScript generators only checked parameter.dataFormat == "binary", so the array parameter could miss file-array handling and fall back to csv-style form serialization instead of repeated multipart fields.

Cross-Generator Consistency

This brings the TypeScript client generators in line with existing generator behavior for the same OpenAPI shape:

• modules/openapi-generator/src/test/resources/3_0/form-multipart-binary-array.yaml already defines the canonical multipart binary array case as files: { type: array, items: { type: string, format: binary } }.
• Spring server tests assert this shape is generated as List<MultipartFile> files with @RequestPart("files").
• JAX-RS/Jersey tests assert multipart file arrays are generated as List<FormDataBodyPart> files.
• Java client tests assert multipart arrays become List<File>/Collection<Resource> and are added with repeated formParams.addAll("files", ...) entries.
• JavaScript client tests already treat multipart binary arrays as passthrough collections instead of csv-joined form values.
• Go codegen has regression coverage for array-of-binary operation parameters, confirming that the file signal comes from the array items.

So the fix does not introduce a new TypeScript-specific convention; it makes the TypeScript client generators honor the same item-level binary metadata that other generators already rely on.

Regression Safety

• typescript-axios and typescript-inversify templates do not branch on isFile; they use isCollectionFormatMulti for repeated field serialization, so the change is scoped to the multipart array serialization path.
• Existing typescript-axios echo sample regeneration produced no diff.
• Existing typescript-inversify petstore sample regeneration produced no diff.
• The new typescript-fetch sample was re-generated after commit cleanup and committed exactly as generated.

Validation

• ./mvnw -pl modules/openapi-generator -am -Dtest=TypeScriptFetchClientCodegenTest,TypeScriptAxiosClientCodegenTest,TypeScriptInversifyClientCodegenTest -Dsurefire.failIfNoSpecifiedTests=false test
• ./bin/generate-samples.sh bin/configs/typescript-fetch-multipart-file-array.yaml
• ./bin/generate-samples.sh bin/configs/typescript-axios-echo-api.yaml
• ./bin/generate-samples.sh bin/configs/typescript-inversify.yaml
• Earlier validation on this branch before expanding the TypeScript scope:
  • ./mvnw -pl modules/openapi-generator-cli -am -DskipTests package
  • ./mvnw clean package
  • ./bin/generate-samples.sh ./bin/configs/*.yaml
  • ./bin/utils/export_docs_generators.sh

Related upstream issue: OpenAPITools#22597

PR checklist

• Read the contribution guidelines.
• Added generator-level regression coverage for the affected TypeScript clients.
• Rebased onto the fork default branch and cleaned the branch into two semantic commits.
• Upstream PR opened for maintainer review: [typescript] Align multipart file array handling OpenAPITools/openapi-generator#24133.

[hwisu]

Superseded by upstream PR OpenAPITools#24133.