fix(spring): split response content types

[maiph]

Fixes #8701

Summary

• add an opt-in splitResponseTypes option to the spring generator
• split Spring operations into separate generated methods per response content type
• keep the existing output unchanged by default to preserve backwards compatibility
• document the new option and add a focused regression fixture/test

Why

Spring cannot disambiguate multiple API operations on the same path and method when they differ only by response Accept/produces values unless separate methods are generated. The previous attempt in #12462 pushed this behavior into core; this change keeps it Spring-local and opt-in.

Testing

• ./mvnw -q -pl modules/openapi-generator -am -DskipITs -Dsurefire.failIfNoSpecifiedTests=false -Dtest=SpringCodegenTest test
• ./mvnw -q -pl modules/openapi-generator -am -DskipITs -Dsurefire.failIfNoSpecifiedTests=false -Dtest=SpringCodegenTest,AbstractJavaCodegenTest,DefaultCodegenTest test
• ./bin/utils/export_generator.sh spring

---

Summary by cubic

Adds an opt-in splitResponseTypes option to the Spring generator to emit one method per response media type when an operation returns multiple content types. The default output stays the same and avoids Spring mapping conflicts when operations differ only by produces/Accept.

• New Features

  • Add splitResponseTypes (default false) to generate one method per response content type.
  • Each method has a media-type-specific produces and return type (e.g., application/octet-stream returns a resource/binary type).
  • Document the option and add a focused regression test for the original issue.

• Migration

  • Enable with -p splitResponseTypes=true (CLI) or splitResponseTypes: true in config.

^{Written for commit c440eb5. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 4 files

_{Re-trigger cubic}