The type of a huge integer literal no longer costs a division by a power of ten as large as it

[enumeratio]

Fix #431.

• The .type of an integer literal past the double range: literalEnclosureType now returns no enclosure as soon as the literal's double value is ±Infinity, before any bignum work. Both bounds would have had to be finite doubles, so the type is unchanged (integer<1..>, integer<..-1>).
• bigintDigits past the pow10 cache limit (100 000 digits): it now estimates log10(n) from the top hex digits and the hex length, and makes one exact n >= 10^k comparison only when the estimate is within its rounding margin of an integer. Below the limit nothing changes.
• bigRatioToFloat, which computes .re: it reads bit lengths from the hex form, and when the numerator is wider it shifts only the numerator. The quotient and the sticky bit (which decides rounding) are the same as before.

ce.number(7n * 10n ** BigInt(d) + 12345n).type, per new literal (ms, median of 7):

digits	before	after	toString(16)
25 000	0.41	0.05	0.01
100 000	6.26	0.13	0.06
200 000	21.0	0.28	0.14
1 000 000	193	1.3	0.61

New tests check:

• bigintDigits against toString().length around 10^k on both sides of the cache limit, and for random values;
• rationalAsFloat at exact ties and just above them, with a wide numerator;
• the type of a 400-digit and a 200 000-digit literal.

[arnog]

Landed on main as de19cf1 with your commit's content, credited as co-author. Two small edits on the way in: the CHANGELOG entry moved to a new [Unreleased] section (0.153.0 had shipped), and the four rationalAsFloat tie tests now use 2^200 denominators so the quotients stay finite (near 2^953; at 2^1053 the expected value was Infinity and the tests passed without the sticky bit). Thanks for the fix and the careful error analysis.