openapi: numeric bounds and defaults outside float64 range or in valid non-JSON forms are rejected or dropped

[OmarAlJarrah]

Summary

Numeric constraints and defaults are routed through a float64 parse path, which defeats the arbitrary-precision (BigVal) design:

• A bound whose magnitude exceeds float64 range (e.g. minimum: 1.8e308) is silently dropped — the produced schema carries no constraint and no diagnostic is emitted. A side-by-side IR dump against a schema with no minimum at all is byte-identical.
• A slightly larger magnitude is rejected as a type mismatch.
• A numerically valid YAML value with a leading dot (.5) is rejected as invalid JSON.

Reproduction

Silently dropped:

openapi: 3.1.0
info: {title: t, version: '1'}
paths: {}
components:
  schemas:
    N: {minimum: 1.8e308}

Rejected as invalid JSON:

openapi: 3.1.0
info: {title: t, version: '1'}
paths: {}
components:
  schemas:
    N: {minimum: .5}

Root cause

compilers/openapi/value.go / constraints.go parse numeric literals via float64 (and/or a strict JSON-number path) rather than preserving them as BigVal decimal strings, so out-of-range magnitudes overflow or round away and valid-but-non-JSON spellings are rejected.

Expected

Numeric constraints, defaults, enum values, and literals must be preserved losslessly as BigVal decimal strings, independent of float64 range and of JSON-vs-YAML number spelling. A value that genuinely cannot be represented should be reported with a diagnostic, never silently dropped.