fix(bigint): correct log2(10) buffer-estimate constant

[LukaszRozmej]

Summary

Two related commits:

1. Correctness fix. The integer-math buffer-length estimate added to 17_bigint.patch (BigInteger decimal parsing) used the constant 3321928095 with a binary >> 35 shift. That constant is round(log2(10) × 10⁹) — a decimal scaling of log₂(10) — but it is divided by 2³⁵ (a binary unit). The unit mismatch makes the effective per-digit word multiplier 0.09668083 instead of the intended log2(10)/32 = 0.10381025 — a 6.87% under-estimate (matching the round(log2(10)·2³⁰) = 3566893132 the comment claims). Fixed by using 3566893132.

2. Helper extraction. The same estimate was duplicated across three sites (NumberToBigInteger, DivideAndConquer, Recursive), each with its own copy of the fixed-point constant. Extracted into a single EstimateWordCount static local function so the constant lives in exactly one place and can never drift between sites again. The overflow-checked additions on the two inner sites are preserved.

Impact of the bug

The buffer carries a +3 slack. The deficit ≈ 0.00713 · digitCount − 3 overtakes that slack once the digit count passes ~424, after which the result buffer is undersized:

digitCount=424:   needed=45    estimate=44    (short by 1)
digitCount=1000:  needed=104   estimate=100   (short by 4)
digitCount=5000:  needed=520   estimate=487   (short by 33)
digitCount=100000:needed=10382 estimate=9672  (short by 710)

All three sites share the defect. An undersized buffer leads to out-of-bounds writes during conversion — reachable by parsing a BigInteger from any numeric string of a few hundred or more digits.

Verification

Confirmed the corrected constant never under-allocates for digit counts from 1 to 2,000,000.

🤖 Generated with Claude Code

[maximmenshikov]

@LukaszRozmej let's make a run in Actions for this particular patch.