openapi: response extensions dropped everywhere, links dropped on error responses

[OmarAlJarrah]

Summary

A Response Object can carry x-* extensions and a links map. Neither reliably survives lowering,
and nothing is reported either way.

• Response x-* extensions are dropped at every response, success or error. The operation, the
  media type, a header and a parameter each read their own extensions
  (schema.ExtensionsOf is called at four sites in compilers/openapi/internal/operation); the
  Response Object is not one of them. x-* is legal on every OpenAPI object, and
  ir-design.md says it maps to namespaced Unmodeled — which is why every node has an
  Unmodeled map. ir.Response and ir.ErrorCase both have one; neither is written from the
  response's own extensions.
• links survives on a success response and is dropped on an error one. lowerResponse
  preserves the raw links node under openapi:links with ReasonNoIRHome; the error branch
  (lowerErrorCase) has no counterpart, so the same declaration disappears depending only on
  whether the status is < 400.

Reproduction

openapi: 3.1.0
info: {title: Adj, version: "1.0.0"}
paths:
  /t:
    get:
      operationId: getT
      responses:
        "200":
          description: ok
          x-note: kept on success
          links:
            self: {operationId: getT}
          content:
            application/json: {schema: {type: string}}
        "404":
          description: gone
          x-note: dropped on error?
          links:
            retry: {operationId: getT}
          content:
            application/json: {schema: {type: string}}

go run ./cmd/morphic compile adj.yaml emits one diagnostic (about the error response's media
type) and nothing about either loss. In the emitted IR:

• the success Response.Unmodeled holds openapi:links only;
• the ErrorCase.Unmodeled holds openapi:content only;
• the string x-note does not appear anywhere in the document, and neither does the retry link.

Expected

x-* on a Response Object reaches Response.Unmodeled / ErrorCase.Unmodeled as a
vendor_extension entry, as it does at every other object. links on an error response is
preserved the way the success path already preserves it, with the same reason and the same
diagnostic — one rule, not one per status range.

Found while working on #39, which covers a different set of drops in the same walk and does not
touch these two.