openapi: 3.2 additionalOperations are dropped entirely and silently

[OmarAlJarrah]

Summary

OpenAPI 3.2 adds additionalOperations to the Path Item Object, a map from a non-standard HTTP
method to a full Operation Object. The compiler never reads it: lowerPathItem iterates the fixed
httpMethods list and nothing else, so every operation declared there is dropped — with its
operationId, parameters, request body, responses and callbacks — and no diagnostic is emitted.

This is the largest unit of loss found so far: not a field on a node that still lowers, but whole
operations that never reach the IR at all.

ir-design.md already anticipates the capability. HTTPBinding.Method is documented as:

Method      string             // as sent on the wire (OpenAPI 3.2 additionalOperations keys …

so the IR has the field; only the compiler side is missing.

Reproduction

openapi: 3.2.0
info: {title: T, version: "1"}
paths:
  /x:
    get:
      operationId: getX
      responses: {"200": {description: ok}}
    additionalOperations:
      PURGE:
        operationId: purgeX
        responses: {"200": {description: ok}}

Compiles with no diagnostics at all. The document contains exactly one operation, getX
(method=GET); purgeX is absent entirely.

Note that a standardized method under additionalOperations is already rejected by the upstream
validator ("method [QUERY] is a standardized HTTP method and must be defined in its own field"), so
only the non-standard spelling reaches this path — which is the spelling the field exists for.

Expected

additionalOperations entries lower to ir.Operations like any other, with the map key as
HTTPBinding.Method, per the ir-design.md note above. Failing that, the document must not lose
them in silence.

This is a missing capability rather than a regression, and it predates #272 — found while reviewing
that PR, which closes #39 and covers field-level drops on operations that do lower.