For radixes other than 2, 4, 8, 10, 16 and 32, V8 folds each 32-bit digit
chunk with `value * multiplier + part`. Node's arm64 builds fuse that
multiply-add into one rounding and its x64 builds round twice, so long
inputs such as parseInt("9007199254740993", 36) answer
1.9896986116031812e+24 on arm64 and 1.9896986116031807e+24 on x64. The
runtime followed the same split only through the C compiler's default
contraction, and the committed string oracle held one architecture's
answers: regenerating it on x64 replaced the two arm64 values, failing the
string oracle tests on macOS arm64.
scr_radix_fold now writes out each form: fma() on aarch64, and an unfused
multiply and add with contraction disabled elsewhere, so the result matches
the same architecture's Node under any contraction setting. The generator
records the architecture-dependent cases once per architecture
("parseInt.arm64" / "parseInt.x64") from a listed table and checks the
current machine's answer against Node, so the committed file is the same
whichever machine generates it. The C harness runs the cases for the
architecture it was built for.