Request body with multiple content types drops JSON body and emits empty form submission

[halotukozak]

Description

When a request body offers multiple content types (e.g. application/json + application/xml + application/x-www-form-urlencoded), the generator drops the JSON body and emits an empty form submission, producing a request that sends nothing.

Reproduced with the canonical Swagger Petstore POST /pet (addPet) and PUT /pet (updatePet), whose request body is:

content:
  application/json: { schema: { $ref: '#/components/schemas/Pet' } }
  application/xml: { ... }
  application/x-www-form-urlencoded: { ... }

Generated output:

public suspend fun addPet(): HttpResult<JsonElement, Pet> = safeCall {
    client.submitForm(
        url = """${baseUrl}/pet""",
        formParameters = parameters {
        }            // <-- empty, and no `body` parameter on the function at all
    ) { applyAuth() }.toResult()
}

The Pet body is never sent.

Root causes

1. Content-type priority (ContentType enum order: MULTIPART_FORM_DATA, FORM_URL_ENCODED, JSON_CONTENT_TYPE). SpecParser picks the first matching entry, so application/x-www-form-urlencoded wins over application/json. For request bodies, JSON should be preferred.
2. Form/multipart extraction ignores $ref bodies. ParametersGenerator.buildFormParameters / buildMultipartParameters read requestBody.schema.properties, but TypeRef.properties only returns properties for TypeRef.Inline — a $ref (TypeRef.Reference) yields emptyList, so the form has no fields even when the chosen content type is form.

Acceptance criteria

• When a request body offers both JSON and form/multipart, JSON is preferred (or the selection is otherwise sensible and documented).
• Form/multipart bodies whose schema is a $ref extract the referenced schema's properties.
• addPet / updatePet from the Swagger Petstore spec generate a body: Pet parameter and send it.
• Covered by a test (the vendored fixtures/public/swagger-petstore.json is a good candidate).

Discovered in

Manual review of generated output for vendored public specs (PR #90, issue #47).