test(runtime): cover JSON escapes end to end and pin the i64 boundary pair

[nankingjing]

Follow-up to #3270, which added the first batch of JsonValue parser/renderer unit tests. This is the second batch that was promised in review there: escape round-trips and the i64 boundary pair.

It is a standalone branch off main and does not depend on #3270, #3273 or #3304.

Why the earlier groups did not catch these

The two areas below were verified as real gaps by mutation testing against the current implementation on main, not just by reading it.

Escapes were only asserted on the renderer's output. Both existing tests that touch escapes (escapes_control_characters, and the round-trip test in #3270) build their input from render_string or from escape-free JSON, so parse was never fed a single backslash escape. Mutating the parser left the whole suite green:

mutation	on main	with this PR
parse_escape: 'n' => '\n' becomes 'n' => 'X'	all pass	2 new tests fail
parse_escape: 't' => '\t' becomes 't' => 'T'	all pass	2 new tests fail
parse_escape: '/' => '/' becomes '/' => '!'	all pass	1 new test fails
parse_unicode_escape: 0..4 becomes 0..3	all pass	2 new tests fail
parse_unicode_escape: to_digit(16) becomes to_digit(10)	all pass	2 new tests fail
parse_number: parse::<i64>() becomes parse::<i32>() widened	all pass	1 new test fails

The same six mutations also survive #3270's expanded 13-test suite, so this is not something that lands with that PR.

The rejection test did not pin the range. parse_rejects_integers_outside_the_i64_range uses a 25-digit literal, which an i32-backed parser rejects too. It pins "rejects absurdly large numbers", not "the accepted range is i64".

What is added

Four tests, appended to the existing module in rust/crates/runtime/src/json.rs, same helpers and naming as the surrounding tests:

• parses_escape_sequences_inside_strings - \n, \t, \r, \b, \f, \/, \", \\ through parse, asserting the decoded value rather than the literal letter.
• parses_four_digit_unicode_escapes - A and é in both hex cases, that all four digits belong to the escape, and that three digits, non-hex digits and a lone surrogate are rejected.
• round_trips_parsed_escapes_through_the_renderer - parse, render, re-parse and compare, over the escape set above, plus an object key carrying a newline so the key path is covered on both sides.
• parses_the_i64_boundary_and_rejects_the_values_past_it - 9223372036854775807 and -9223372036854775808 parse to i64::MAX and i64::MIN exactly, and 9223372036854775808 / -9223372036854775809 are rejected.

Verification

Local, on the GNU toolchain (stable-x86_64-pc-windows-gnu, anaconda MinGW), against the implementation on main:

• cargo test -p runtime --lib json:: - 6 passed, 0 failed (2 pre-existing, 4 added).
• Each of the six mutations in the table above applied one at a time, tests run, then reverted: the new tests fail and the pre-existing ones stay green. Reverted, the suite is green again.
• rustfmt --edition 2021 --check clean; cargo clippy -p runtime --lib --tests reports nothing in json.rs.

Two honest caveats:

• CI has never run on this repo's fork PRs - every run sits at action_required behind the fork-approval gate - so this suite is not CI-verified. The results above are local only.
• The crate's lib test target does not currently compile on Windows out of the box: mcp_stdio.rs and mcp_tool_bridge.rs have #[cfg(test)] modules using std::os::unix::fs::PermissionsExt with no cfg(unix) gate, so set_mode is missing. To run the tests locally I applied a local-only, uncommitted no-op set_mode shim to those two files and reverted it afterwards; this PR touches none of that - it changes only rust/crates/runtime/src/json.rs, 116 added lines, 0 deletions.

Because both this and #3270 append to the end of the same test module, the two will conflict textually if #3270 merges first. The resolution is to keep both blocks.

[1716775457damn]

The mutation-testing evidence is compelling — escapes only being asserted on renderer output while the parser never received a raw backslash escape is a genuine blind spot, and pinning the i64 boundary pair closes the other real gap. Thanks for making this a standalone branch off main.

[1716775457damn]

Thanks for the standalone second batch — mutation testing makes a strong case for both gaps. Just to confirm: the i64 boundary pair pins i64::MAX and i64::MIN specifically? And are u64/f64 boundaries covered elsewhere, or would those be a natural third batch?