openapi: a standard method the compiler does not lower would be unmounted in silence

[OmarAlJarrah]

Summary

Two vocabularies decide what a Path Item Object's keys mean, and nothing holds
them together:

• operation.httpMethods — the fixed method fields this compiler lowers.
• soa.IsStandardMethod — the methods the library recognizes, which
  undeclaredPathItemKeys grades against so a method is never reported as an
  undeclared key.

They hold the same nine names today, so nothing is currently lost:
#293 closed by adding query
to httpMethods and reading additionalOperations beside it.

They are maintained independently, though — one tracks the specification, the
other tracks the lowering. A method the library learns before this compiler does
falls between them: IsStandardMethod says it is a declared method, so the
census leaves it alone; pathOperations has no field for it, so no operation is
mounted. The whole operation — its operationId, parameters, request body,
responses, and every type reachable only through them — reaches the IR in no
form, with no diagnostic. That is the same loss
#293 reported for
additionalOperations, arriving through the other door.

Grading it as an undeclared key instead is not the answer: it would keep the
value but say something false about the document, since a method the
specification defines is a key the Path Item Object declares.

What would close it

A check that the two vocabularies agree, and a diagnostic when they do not — a
declared method with no lowering is a compiler gap, so it belongs on the
degraded-construct channel naming the method, rather than being folded into the
undeclared-key census.

The cheap version is a test asserting httpMethods covers every name
soa.IsStandardMethod accepts, which turns a future library upgrade into a red
build instead of a silent drop. That is the same shape as the 2020-12 vocabulary
test in the schema walk.