openapi: explode and allowReserved at in: querystring are kept in silence

[OmarAlJarrah]

OpenAPI 3.2 forbids style, explode and allowReserved at in: querystring: the location
binds the whole query string from the parameter's content, so its serialization is stated by
the media type and nothing else. The bundled parser enforces only the first of the three, and
the compiler reports what the parser gives it — so two of the three reach the IR with nothing
said about them.

Reproduction

openapi: 3.2.0
info: {title: T, version: "1"}
paths:
  /a:
    get:
      operationId: explodeOnly
      parameters:
        - name: whole
          in: querystring
          explode: false
          content: {application/x-www-form-urlencoded: {schema: {type: object}}}
      responses: {"200": {description: ok}}
  /b:
    get:
      operationId: reservedOnly
      parameters:
        - name: whole
          in: querystring
          allowReserved: true
          content: {application/x-www-form-urlencoded: {schema: {type: object}}}
      responses: {"200": {description: ok}}

$ morphic compile qs.yaml -skip-validate 2>&1 >/dev/null
$ echo "diagnostics: $?"
diagnostics: 0

Both parameters lower with the declared keyword on the binding — explode: false and
allowReserved: true — and neither compile says anything. A style at the same location is
refused loudly:

error openapi/validation/validation-allowed-values ...: parameter field style is not allowed for in=querystring

Why the keywords are kept

Keeping them is deliberate and should stay: the document states them, and dropping content a
document states is an emitter's call rather than a compiler's. The gap is the silence, not the
value. A reader of the IR cannot tell a binding whose explode was written from one where the
location simply has none, and an emitter has no signal that what it is reading is illegal at
that location.

Expected

explode and allowReserved declared at in: querystring are reported — the same way style
already is — while still lowering as declared. Whether that report is this compiler's own
diagnostic or belongs upstream in the parser's validation table is the decision to take here;
the asymmetry between the three keywords is what should not survive it.