fix(compilers/openapi): stop rounding raw-preserved numbers

[OmarAlJarrah]

Summary

annotation.RawFromNode decoded a YAML node into any and re-marshalled it as JSON. yaml.v3 resolves an out-of-int64 integer and every decimal into float64, so the one channel whose documented promise is verbatim preservation quietly rewrote its numbers:

source	preserved as (before)
12345678901234567890123	1.2345678901234568e+22
1.000000000000000000001	1
-9223372036854775809	-9223372036854776000
1.10	1.1

One conversion backs every raw-preservation site, so all four were affected: x-* extensions, oneOf/anyOf sibling preservation, the §4.7 validation-only carve-out, and tuple items-after-prefix. #23 fixed the same class of bug in the Value/BigVal channel; this is the raw channel's version of it.

The fix renders the node tree directly, taking numeric scalars from their source text via value.NumericLiteral — the helper that already backs the Value channel, and that resolves YAML's integer bases, so 0o17 still reads 15 rather than 17.

Walking the tree means the structural work the decode used to do has to be done here, so merge-key (<<) expansion, duplicate-key rejection, non-string-key refusal, alias following — including an alias used as a key — sorted object keys, and the fallback that keeps a scalar whose tag yaml.v3 resolves no type for are all reproduced deliberately and pinned by tests.

Three of those were found by reviewing the walk against the decode rather than against its own tests: an alias key, an unresolvable tag (!foo, !!python/object), and an untagged node all converted before and were refused after. Each dropped a construct the source did write, behind a "could not be serialized" warning. They are fixed in the second commit, and the equivalence corpus gained the shapes that found them.

ir.UnmodeledEntry.Value's doc comment described the rounding as intended behaviour ("normalizes … number spelling"), so it is corrected to say what now holds.

Behaviour changes beyond the rounding

• An explicitly tagged huge integer (!!int 12345678901234567890123) used to fail to convert and be dropped with a diagnostic. It is now preserved exactly.
• A literal whose rendered form is not JSON is refused rather than spliced into the document. NewBigVal accepts binary-exponent literals and stores them verbatim (ir: NewBigVal accepts binary-exponent and leading-zero literals, storing non-JSON canonical forms #45, open), so !!float 1p4 would otherwise have put 1p4 into a RawValue. Refusing matches what the old decode did with that input and leaves ir: NewBigVal accepts binary-exponent and leading-zero literals, storing non-JSON canonical forms #45 to be settled on its own terms.

Deliberately out of scope

Timestamps still normalize to RFC 3339 and !!binary still carries decoded bytes rather than its base64 text, which costs ill-formed UTF-8 its identity to U+FFFD. Those are a different mechanism from the float64 rounding and are filed as #242, noted in the code and in the Value doc comment rather than swept in here.

Test plan

• TestRawFromNode_KeepsNumericLiteralsExact — the regression, over the spellings the old conversion rewrote, including a significant trailing zero and both integer boundaries.
• TestRawFromNode_ResolvesYAMLIntegerBases — the half that must not become verbatim, so the fix cannot be "read the source text" applied too far.
• TestRawFromNode_PreservesMergeAndOrderingSemantics and TestRawFromNode_RefusesWhatJSONCannotName — the structural behaviour the walk had to reimplement, and the refusals compilers/openapi: a failed raw conversion preserves nothing while its diagnostic claims otherwise #144 depends on.
• TestRawFromNode_DiffersFromTheOldDecodeOnlyInNumbers — the equivalence oracle. The old conversion is kept in the test file, and the claim is that rounding the new output through float64 reproduces it. Reading two implementations cannot show they agree; this can.
• Bounds: an alias cycle, a multiplicative alias chain, a << chain that recurses without passing back through the node walk, and an alias chain longer than any source could mean.
• testdata/conformance/openapi/numeric-precision.yaml gains a preserved property carrying high-precision numbers in an extension and under not. The corpus had no case with a number float64 cannot hold, which is why nothing caught this.

Verified by mutation rather than by inspection — each of these was planted and confirmed to redden: reverting to the float64 decode, inverting merge precedence, dropping the duplicate-key check, dropping key sorting, accepting non-string keys, removing the bounds (which turns a clean refusal into a stack overflow), un-resolving alias keys, refusing unresolvable tags again, and reading n.Tag in place of ShortTag. The last of those initially survived, because the row meant to catch it was testing the parser rather than the dispatch; it is now covered by a case that distinguishes them. Restoring the original bug reddens the conformance case on all four preserved values, so the fixture is load-bearing rather than decorative.

Full gate green: gofmt, go vet, golangci-lint, go build, and ./scripts/check-coverage.sh at 100% of 4469 statements.

Fixes #32