[P2] JSON admits integer values that the runtime silently changes #18

Reproduced during the 2026-09-04 language review at a20753c6cff96ee86758744e227a04460234a832. Priority: P2.

"{\"id\":9007199254740993}".parse_json().to_json()

Observed returned string: {"id":9007199254740992}. Numeric source literals also collapse those distinct integers to the same value. This reproduces in optimized execution.

The numeric tokenizer converts through f64; see tokenizer.rs. The VM JSON parser likewise uses floating-point values, and write_script_json emits the resulting number. Byte limits, depth limits, and JSON syntax validation do not preserve integer identity.

Using floating-point arithmetic is a reasonable design choice; presenting a general JSON tool/dataflow boundary without a clear precision policy is the problem. A schema accepting an integer can still accept the changed identifier. Support exact integer values where required, reject unrepresentable values at ingress, or publish a restricted numeric domain and require string identifiers beyond it. Rejection must happen before the rounded value is passed to a tool. Add boundary tests covering positive and negative integers around the safe range and host injection as well as script parsing.

Acceptance: implement the described correction, publish the resulting language contract, and add focused regression coverage including applicable capability, streaming-parser, and resource-limit cases.

Fix and executable regressions: PR #19. Workspace tests, explicit vendor suites, formatting, strict Clippy, and the Linux ARM64/RISC-V and Windows GNU compile checks pass locally. All GitHub Actions checks pass on f1e775f, including Linux tests, fuzzing, AddressSanitizer, and Miri. This issue remains open until the fix is merged.

Boundary tests also found negative JSON numbers losing their sign in compatibility-tokenizer reconstruction. The fix copies validated decoded JSON directly into VM values and covers signed boundary values.