Support exact literal and bounded decimal numeric conversion

[CaelmBleidd]

Numeric conversions such as Number("42") and unary +value for a bounded multi-character string stopped at the StringToNumber limitation even when their values were directly representable.

Fold immutable literal strings with the ECMAScript StringNumericLiteral grammar and binary64 rounding, rejecting Java-only numeric suffixes, hexadecimal floats, and non-ECMAScript whitespace. Symbolic strings use a guarded UTF-16 integer parser: optional sign, ECMAScript trim, at most 15 decimal digits and 32 already bounded code units. Integer accumulation uses bit-vectors and one binary64 conversion rather than execution branches per character. Empty strings, sign-only NaN, negative zero, and nullish alternatives retain their distinct values.

Other symbolic formats and larger strings remain explicit unsupported paths with their ordinary siblings retained. Existing configured string/array bounds are unchanged. The old unsupported fixtures used literal "42"; they now use ordinary object ToPrimitive to keep testing the same unsupported/sibling contracts. A new low-level conditional test checks that both the numeric and literal-string alternatives convert exactly.

Depends on #559 for the common runtime reference contracts; this PR adds only conversion code and relevant regression updates.

Validation: 27 focused tests passed with zero failures or skips (6 new source/native/parser tests, 12 conditional-value tests, 9 runtime-boundary tests). Strict TS main/test lint passes with zero issues. Reverting the conversion callers to their exact parent reproduces the source literal conversion failure; restoring the change passes. The unused parsing helpers/shared whitespace predicate remain present during that fail-before check. Full suites are left to CI; corpus coverage/performance will be measured on the combined runtime.