Intl.NumberFormat groups in fixed 3-digit runs: en-IN gives 1,234,567.891 where node gives 12,34,567.891 #9450

new Intl.NumberFormat("en-IN").format(1234567.891)   // node "12,34,567.891"   perry "1,234,567.891"

Grouping is hard-coded to a comma every three digits. CLDR defines per-locale grouping sizes, and the Indian system groups the first three digits then in pairs (12,34,567) — the most common non-3-digit pattern, used by a very large number of users.

This is a defect in Intl.NumberFormat itself, proven standalone: it is not a consequence of toLocaleString argument handling, and PR #9448's delegation fix cannot reach it. That PR carries a control row demonstrating it independently, and replaces the affected fixture rows with comments naming node's expected output so the suite stays green and this stays visible.

Everything else in Intl.NumberFormat was verified byte-identical to node across de-DE / fr-FR / ja-JP: decimal, percent, currency EUR in both locales, compact short and long, minimum/maximum fraction digits, minimumIntegerDigits, and useGrouping. Only the grouping size is wrong, so this is a narrow fix, not a rewrite.

Fix shape

Read the grouping sizes from CLDR for the resolved locale (primary and secondary group size) instead of assuming 3. icu4x carries this data; the number formatter already resolves the locale for other decisions.

Verification bar

A gap fixture byte-compared to node --experimental-strip-types, demonstrated failing on unfixed origin/main, covering: en-IN at 4, 5, 6, 7 and 9 digits (the pattern only diverges above 5); en-US, de-DE, fr-FR as 3-digit controls that must not change; useGrouping: false; and the same values through Number.prototype.toLocaleString("en-IN") so both spellings are pinned.

Found while fixing #9414.