compilers/openapi: extract reference resolution into its own package

[OmarAlJarrah]

resolve.go holds reference resolution. Its site type and the free functions around it move out
separately, to the annotation package that reads them; what remains here is resolution itself.

Reference resolution is deliberately not promoted to compilers/compile: two of the three
compilers need it and they need it by different mechanisms, which is the shape that looks promotable
and is not.

Resolution recurses, so this package needs a bounded-recursion test: a deep or cyclic input must be
refused by an explicit depth counter rather than by exhausting the stack. The depth field moves
from the lowerer struct to an explicit parameter, which is what the bounded-recursion rule wants
regardless — and the risk of that change is a path that forgets to increment, which only a test
reaching that path will catch.

Acceptance

• The named files hold no lowerer method.
• Golden output byte-identical, and the two-order and ID-collision oracles green.
• Any diagnostic-ordering change explained individually. Diagnostics move from central accumulation
  to bottom-up returns, so some reordering is expected — each instance is understood, never absorbed
  with -update.
• Table-driven unit tests built from a literal Ctx and a fresh compile.NewTypes(0), needing no
  document fixture.
• Coverage still exactly 100%.

Part of the Tier-1 conversion in docs/micro-compiler-design.md §5 and §8.1.

Also settle here: does the recursion guard belong in the framework?

docs/micro-compiler-design.md §3 lists the bounded-recursion guard as "promote only if the drafts
show need" and leaves the decision unassigned. This is where it becomes concrete, since depth stops
being a struct field here.

Check what the GraphQL (#20) and Protobuf (#21) drafts actually do about recursion depth before
deciding. The promotion rule is evidence from all three compilers, and the OpenAPI cap of 256 is
known to be wrong for an SDL-shaped source — which is an argument that the guard may be shared
while the cap stays per-compiler. Record the finding either way, so the next person does not
re-derive it.

[OmarAlJarrah]

Two findings from the investigation, both of which changed what this issue could be.

resolve.go does not split where the file boundary is

The design's §5 dependency diagram puts resolve beneath the cycle and calls schema ⇄ compose "the one genuine cycle". The type checker disagrees: resolve.go used nine symbols from schema.go (attachDeclaredAnnotations, falseSchema, hoistDeclarationHome, internAlias, recordDeclarationResidue, schemaAdmitsNull, schemaBody, schemaConstraints, diag) and two from compose.go, while schema.go used five back (schemaRef, carriedSchemaRef, homeDeclaration, refTargetSchema, resolveComponentRef).

Resolving a $ref hoists the sub-schema it names, which lowers a schema, which resolves the references inside it. That is one algorithm, and no package boundary runs through it.

What the wrong diagram hid is that there is a boundary — between two questions, not between files:

• What does this $ref name, and is something already interned there? Needs the document's own path, what it declares, and the type registry. Seven functions. This is now internal/resolve.
• Follow it far enough to lower what it points at. The schema walk reached through a reference. Eight functions. These stay and go to internal/schema at compilers/openapi: extract schema lowering and composition #176.

So this issue is delivered as the first half, and #176 absorbs the second. The alternative — creating the package anyway with the nine schema symbols arriving as injected function fields — would have been the cycle rewritten as a struct, and deleted again at #176.

The depth field stays where it is for the same reason. Its recursion runs through schemaRef, which is called from five files; threading it as a parameter reaches all of them, so it belongs with the conversion that moves them.

The recursion guard is not promoted, and one premise here was wrong

Read from both drafts rather than assumed:

Compiler	What is bounded	Cap	Shape
openapi	schema nesting	256	counter on the lowerer
openapi	value nesting	128	explicit parameter
graphql	type nesting	256	counter on the lowerer
graphql	value nesting	128	explicit parameter
protobuf	custom-option nesting	32	explicit parameter

Three things follow. All five sites are the same three lines — a counter, a named cap, a degradation that reports rather than crashes — with no shared state and no shared cap. The caps track what is bounded rather than which compiler bounds it: both compilers that lower values chose 128, both that lower types chose 256.

And this issue's premise that "the OpenAPI cap of 256 is known to be wrong for an SDL-shaped source" is not so — the GraphQL draft independently chose 256 for exactly that. The argument that the guard might be shared while the cap stays per-compiler rested on a difference that does not exist.

Verdict: nothing to promote. Recorded in micro-compiler-design.md §3.3 with the command that re-derives the table, so it is not researched again.