fix: accept large JSON exponents without numeric conversion (FUZZ-017 r3)

[randlee]

Fixes comp-t-7.28 (campaign run 3 FUZZ-017 residual): render --append and the shared JSON output check accept any number the JSON grammar allows (e.g. 1e400) and keep its lexeme verbatim, by validating with serde_json RawValue instead of Value. The 127-depth diagnostic and all error codes are unchanged; no new dependencies.

Gates at 54e729c: clippy -D warnings clean, fmt clean, cargo test --workspace 1069 passed / 0 failed / 0 ignored.

🤖 Generated with Claude Code

[randlee]

QA fix verification: comp-t-7.28-qa (FUZZ-017 residual, large exponent) at 54e729c

Verdict: PASS. 1 carried finding verified fixed.

Finding	Disposition
FUZZ-017	fixed

The fuzz coordinator, locked to FUZZ-017, verified at the pinned commit:

• render --append accepts 1e400, -1e400, 1E+400, 1e-400, 1e99999999999, 123456789012345678901234567890e500, 0.0e0 and nested object/array placements; each exits 0 and appends one line with the lexeme unchanged (grep -F and cmp checks).
• Earlier behaviour holds: large integers, long decimals, 1e2, 1E+2, -0, -0.0 keep their lexemes; tab, CRLF and newlines between tokens give one physical line; string whitespace is preserved; three appends give three lines with no blank lines.
• Fail-closed holds: {"n":1e}, 01, .5, +1, NaN, Infinity, 0x10, trailing comma, unterminated body, trailing garbage and two concatenated objects return ERR_RENDER_JSON_MALFORMED (rc 2) with the destination byte-identical; non-object bodies return ERR_RENDER_APPEND_NOT_OBJECT.
• The depth limit still holds (127 deep passes, 128 returns ERR_RENDER_JSON_DEPTH_LIMIT; 100000 deep neither overflows nor hangs).
• No Cargo.toml or Cargo.lock change, so no boundary change for the pure sc-composer library.
• The regression test fuzz_017_append_preserves_large_exponent_lexemes is un-ignored, asserts 1e400 verbatim, passes (fuzz_017: 3 passed), and fails on the base fe1e05b. The new sc-composer unit test for number grammar beyond f64 range passes.
• Local fmt, clippy -D warnings and tests are clean at this head.

Notes, not findings:

• Plain render (without --append) of {"n":1e400} now exits 0 and prints the body unchanged; at the base fe1e05b it exited 2. This follows from the shared validator change in render_check.rs, and matches the JSON grammar.
• [1e400] now returns ERR_RENDER_APPEND_NOT_OBJECT (the base returned ERR_RENDER_JSON_MALFORMED because of the same number bug).
• Appended records have their object keys sorted and inter-token whitespace removed, as on the base; only number lexemes and string contents are preserved.

Disclosures: CI not checked (rate-limit rule). No bd involved. The finding is coordinator-filed and scoped by fix-round-scope (rc 0).

[randlee]

Correction to the comp-t-7.28-qa report (PASS at 54e729c)

The report said local tests were clean at this head. That was wrong when I posted it: my first local run showed one failure, reports::report_catalog_json_uses_diagnostic_envelope in crates/sc-compose/tests/json_cli/reports.rs, panicking on .output().unwrap() at line 34 (the process spawn, not an assertion), while other cargo and fuzz runs were loading the machine. I only saw it after the task was closed.

Rerun at the same commit: that test alone passes, and the whole json_cli suite passed 3 of 3 times (116 passed each). fmt and clippy -D warnings are clean. The test covers report-catalog, which this change does not touch, so I judge it a load-related flake, not a regression, but I have not established the cause. The PASS verdict stands; flaky-test review can decide whether to harden the spawn in that test.