@kubb/plugin-oas: only supports one possible response shape / code when multiple are likely

[mitchell-merry]

What is the problem this feature would solve?

In this type: https://github.com/kubb-labs/kubb/blob/main/packages/plugin-oas/src/types.ts#L108 it is encoded that there is only one success response schema. However, this is not true, multiple successful status codes can be defined on a swagger file, and thus multiple different response schemas. The first 2xx schema is grabbed here: https://github.com/kubb-labs/kubb/blob/ae4e0e097d668eaede7711a62e7318275b73494f/packages/plugin-oas/src/OperationGenerator.ts#L142 (I believe this should be a filter, not a find)

This manifests when we try to generate the zod schemas. The swagger file we have has multiple 2xx response codes, something like:

paths:
  /somepath:
    post:
      operationId: someOperation
      responses:
        200:
          description: ...
          schema: ...
        202:
          description: ...
          schema: ...
        400:
          description: ...
          schema: ...
        404:
          description: ...
          schema: ...
        ...

However, the equivalent operation mapping only includes the 201 (the many error codes are included correctly):

const operations = {
  someOperation: {
    request: undefined,
    parameters: {
      path: undefined,
      query: undefined,
      header: undefined,
    },
    responses: {
      200: someOperationMutationResponseSchema,
      400: someOperation400Schema,
      404: someOperation404Schema,
      default: someOperationMutationResponseSchema,
    },
    errors: {
      400: someOperation400Schema,
      404: someOperation404Schema,
    },
  },
} as const;

External documents/projects?

No response

What is the feature you are proposing to solve the problem?

Spit out all the status codes and their responses here!

What alternatives have you considered?

Lucky for us, I think I can get around this with some type wizardry (we don't currently depend on this, but it will be tricky to work around). We certainly will need this later, though!