bug: int(), uint(), float() on a string and json.parse number fields saturate, wrap, or accept trailing garbage instead of failing #2789

The string-to-number conversions int(s), uint(s), float(s), and the int, uint, and float fields of a #json struct (json.parse) all go through the same two runtime functions, gray_builtin_string_to_int and gray_builtin_string_to_float. They call strtoll / strtod without checking errno, accept whitespace, and copy the input into a 64-byte stack buffer. STANDARD.md §3.4 says "Conversions that would lose information or are invalid produce check-time or runtime errors", and strconv.to_int / to_uint / to_float already reject each case below.

The last three rows come from the 64-byte buffer: anything past byte 63 is silently dropped, so trailing garbage is never seen and a long value is silently cut. The whitespace rows come from end being allowed to stop at a space.

json.parse into a #json struct uses the same functions, so a JSON document decodes to wrong values with no error:

Expected

Each row above panics (P0084 / P0085; malformed field values in json.parse are a json.parse failure per §7.5.2), or returns the exact value when the input is valid, the same as strconv.to_int / to_uint / to_float.

Actual

The values in the tables, with no diagnostic.

Reproduction

import @json
import @strings

#json
const T struct {
    a uint
}

do main() {
    println(int("9223372036854775808"))                       // 9223372036854775807, expected panic
    println(uint("-1"))                                       // 18446744073709551615, expected panic
    println(float("1e999"))                                   // inf, expected panic
    println(int("42 apples"))                                 // 42, expected panic
    println(int(strings.repeat("0", 400) + "5"))              // 0, expected 5

    mut t T = json.parse("{\"a\": 18446744073709551615}")
    println(t.a)                                              // 9223372036854775807, expected 18446744073709551615
}