[Basharkhan7776]

Fixed #5662

Number.prototype.toPrecision formatted the number with {:.100} and then scanned that string for the first non-zero digit. Number.MIN_VALUE (2^-1074, about 4.94e-324) is still zero at 100 decimal places, so the scan never saw a digit and the exponent fell through to 101.

Number.MIN_VALUE.toPrecision(1) returned "0e+101" instead of "5e-324". The same path was wrong for every finite value whose first significant digit sits past the 100th decimal place, including tiny normals such as 1e-101 and 2 ** -1022. Ordinary values were unaffected.

Every finite f64 is a multiple of 2^-1074, so 1074 decimal places is the exact fixed-point expansion. to_precision now formats with {:.1074} and still rounds through the existing flt_str_to_exp and round_to_precision helpers.

to_precision_subnormal covers the reported calls (toPrecision(1) and toPrecision(21)), the negative value, precisions 2, 17, and 100, values past the old 100-place window, and Number.MAX_VALUE. Existing to_precision tests still pass.

cargo test -p boa_engine --lib builtins::number::tests::to_precision

[github-actions]

Test262 conformance changes

Test result	main count	PR count	difference
Total	53,578	53,578	0
Passed	51,451	51,451	0
Ignored	1,648	1,648	0
Failed	479	479	0
Panics	0	0	0
Conformance	96.03%	96.03%	0.00%

Fixed tests (1):

test/staging/sm/Number/toPrecision-values.js (previously Failed)

Broken tests (1):

test/staging/sm/String/string-upper-lower-mapping.js (previously Passed)

Tested main commit: bea404d173bf74a64b7c7ae39b1bc2da639abeee
Tested PR commit: ae231f4a461835ca55b7c2fd5d872b95b1b9c622
Compare commits: bea404d...ae231f4