json: parser aborts on strings containing lone surrogates combined with escapes

[bobzhang]

Summary

@json.parse crashes the process (an abort from a guard!, not a catchable ParseError) when a JSON string contains a raw lone trailing surrogate together with any escape sequence.

Minimal repro

A 5-code-unit JSON text: " U+DC00 \n "

test {
  let lone_low = String::from_array([(0xDC00).unsafe_to_char()])
  // aborts in StringView::sub (builtin/stringview.mbt guard!) instead of parsing:
  ignore(@json.parse("\"" + lone_low + "\\n\""))
}

Escape-free strings with the same lone surrogate parse fine (the fast path accepts them), so this is an internal inconsistency as well as a totality violation: a parser should either succeed or raise its documented ParseError, never abort.

Root cause

json/lex_string.mbt, ParseContext::lex_string_slow — the local flush helper slices the pending run with the checked ctx.input[start:end] (StringView::sub), which guard!-aborts when the code unit at a slice boundary is a trailing surrogate. The fast path in lex_string uses the bounds-check-only view(start_offset~, end_offset~) and therefore tolerates raw lone surrogates; only the slow path (taken whenever the string contains a backslash escape) crashes.

Affected targets

All backends — wasm-gc, js, and native (the abort is in shared library code; reproduced on all three).

Severity

High for robustness: any consumer parsing untrusted JSON text can be crashed (denial of service) by a short crafted input. Found by adversarial QuickCheck testing (the default Arbitrary String never generates lone surrogates, which is why existing property tests missed it).

[bobzhang]

Resolution direction chosen in #4056, per the design rule that MoonBit Strings stay Unicode well-formed ("unsafe_to_char is indeed unsafe"): instead of letting raw lone surrogates through with unchecked slicing, the string lexer now rejects every unpaired surrogate with the documented ParseError — raw or escaped, fast path or slow path — so no abort path remains and the parser can never produce an ill-formed string. Well-formed pairs (raw astral chars, or pairs split across two \uXXXX escapes) parse as before. Note the deliberate behavior change: "\uD800" and escape-free raw lone surrogates previously parsed into ill-formed strings and are now parse errors (called out prominently in the PR body).