Fix corner-case issues identified in testing

[eemeli]

While putting together tc39/test262#4608, I validated the proposed spec text with a patched fork of FormatJS, and this identified a few places where the spec text needs to be updated:

• Leading zeros need to be discarded, so we count '0012.3' to have three string digits. To do so in the syntax-directed operation, I introduce ZeroDigits as a new syntax rule.

• An elided leading zero needs to be accounted for, so '.45' should count as having three string digits.

• Changes in exponents that reduce the number of leading zeros need to also reduce the string digit count accordingly. This means that when formatted as a percentage, '0.06' should format as if it had only one string digit, rather than three. This adjustment needs to be done potentially twice, as style: 'percent' can be combined with notation: 'engineering' or notation: 'scientific'.

Ping @sffc, @gibson042, @jessealama, @ben-allen for reviews.

[sffc]

TG2 discussion: https://github.com/tc39/ecma402/blob/main/meetings/notes-2025-11-06.md#fix-corner-case-issues-identified-in-testing-10

[eemeli]

This PR was discussed at the recent TC39 plenary, and concluded with support for merging this, once it's been reviewed by @sffc and/or @gibson042.

[sffc]

"0.0650" will have stringDigitCount of 3, yes?

With style percent, it should format as 6.50%, yes?

So I don't see why we need to adjust stringDigitCount in style percent.

I also don't understand why you say that "0012.3" should have stringDigitCount 3, but ".45" should also have stringDigitCount 3. It seems like it would be cleaner if stringDigitCount simply represented the number of significant digits in the string.

[eemeli]

"0.0650" will have stringDigitCount of 3, yes?

No, its string digit count is 5.

With style percent, it should format as 6.50%, yes?

Yes.

So I don't see why we need to adjust stringDigitCount in style percent.

That is required because when multiplying by 100 for formatting the leading zeros need to be dropped.

I also don't understand why you say that "0012.3" should have stringDigitCount 3, but ".45" should also have stringDigitCount 3. It seems like it would be cleaner if stringDigitCount simply represented the number of significant digits in the string.

It's not possible for us to always determine the significant digit count, for example for a value like '120', is it 2 or 3? So we count "string digits" instead, because those we can determine, and use as necessary when formatting. Do note that this is an entirely spec-internal construct, and the string digit count is never directly accessible from JavaScript. It's also well aligned with the existing language of the spec, which constructs formatted strings while considering their digit counts.