test: make the conformance corpus traceable to the capability matrix

[OmarAlJarrah]

Problem

The corpus contract — "one minimal spec per ir-spec-matrix.md row per format that can express it" (CLAUDE.md, architecture.md §5) — is unverifiable: matrix rows have no IDs, the 37 corpus files aren't mapped to rows, and nothing fails when a row goes uncovered. Concretely uncovered today despite ✅ matrix entries and claimed lowering support in ir-design.md §14:

• the xml object → XMLHints
• OpenAPI 3.2 streaming itemSchema/itemEncoding → Content.Item (see also bug openapi: itemEncoding preserved in Extensions despite the first-class Content.ItemEncoding field #38)
• in: querystring parameters
• 3.2 named servers and tag parent/kind
• the OAuth device flow

This is the test that keeps "lossless by default" honest — and when the AsyncAPI compiler lands, its corpus will be built by imitating this one; an unsystematic template gets copied five times.

Proposed direction

Give matrix rows stable keys (a key column in ir-spec-matrix.md). In each compiler's conformance test, declare rowKey → caseFile plus an explicit exclusion list (row X: not expressible / policy-only) and assert the union covers every row marked ✅/⚠ for that format. Add the missing OpenAPI cases. Size: M.

Acceptance

• Removing a corpus case (or adding a matrix row) without updating the mapping fails a test.
• The five uncovered rows above have cases asserting lossless capture.

[OmarAlJarrah]

Some additional uncovered rows, found by walking the corpus against a shipped Go generator's fixture
set. Recording them here rather than opening separate issues, since the mechanism this issue proposes
is what should surface them systematically.

• Response-header required. No conformance case declares it. The only required under any
  headers: key in the corpus is on a multipart part header (multipart-encoding.yaml:23, under
  encoding.file.headers), which is a different construct. OpenAPI defaults response headers to
  optional; oapi-codegen shipped a bug on exactly this axis and carries a compatibility flag for it.
• Vendored and multiple JSON-ish media types. No +json suffix media type appears anywhere in
  the corpus. multi-content.yaml is application/json + application/xml with both schemas a bare
  {type: object} — identical, so nothing forces content-negotiation or per-content naming to
  disambiguate. Two +json variants with different schemas on one response is the case that does.
• Explicit additionalProperties: true. The corpus has false (allof-inheritance.yaml,
  maps.yaml) and absent, never explicit true. The two produce byte-identical IR today —
  AdditionalMode stays AdditionalUnspecified and nothing lands in Unmodeled. Semantically
  equivalent under JSON Schema, so this may be a deliberate drop; if so it is worth stating in
  ir-design.md, because generators do distinguish them by author intent.
• Identifier-hostile names. neutral-naming.yaml covers punctuation well (widget.id,
  filter[name], X-Rate.Limit, com.example.Widget) but has no name beginning with a digit and no
  _id/id pair. Those stress Naming.Canonical differently: a leading digit cannot be fixed by
  word-splitting, and _id/id is distinct in the source but collides after neutralisation.
• Enum edge cases. enum-string.yaml is [red, green, blue] — no collisions, no empty value, no
  punctuation. Collisions and the empty value are covered by ir+irverify: an entity with no name at all passes every oracle #251.
• Literal : in a path template. No path in the corpus contains one. Two paths distinguished only
  by a literal colon segment (/pets:validate, /pets:generate) is a real shape; the template
  travels in HTTPBinding.URITemplate, so a row asserting it survives verbatim is cheap.
• Path-level vs operation-level parameter shadowing. Implemented and correct
  (operations.go:541, shadowedKeys — use-site precedence by (name, in)), but
  param-ref-inheritance.yaml covers $ref inheritance, not this. No conformance row asserts it.

Two larger ones are split out because each is substantial work on its own: #253 (parameter
style/explode matrix) and #254 (inline hoisting positions).