Regression since #119: integer sums stall at round numbers. 10 + 2 == 10, 100 + 25 == 100, 20 - 3 == 20, and a sum += 2 loop stops at 10 #124

What's wrong

PreciseNumber normalizes integers by moving trailing zeros into the exponent: 10 becomes 1E1 and 100 becomes 1E2. Since fc66077 (#119, the fix for #107), CountDecimalDigits (SignificantNumber/SignificantNumber.cs:155) returns -value.Exponent without clamping it. As a result, any whole number ending in 0 is treated as known only to the tens or hundreds place, including one that came from int.ToSignificantNumber(). Add and Subtract then round the result to that place through LowestDecimalDigits (line 163 onward).

Failure scenarios

Measured at HEAD a15223e, then against fc66077^ in a worktree:

The last row shows what happens to an ordinary accumulator: once it reaches 10, every later + 2 rounds back to 10, so a running total of integer counts silently stops growing.

Relation to existing issues

• Measured trailing zeros count as insignificant: Parse("1.20") has 2 sig figs, so 1.20 × 1.23456 = 1.5 and 9.81 × 10.0 = 100 #120 has the same root cause: trailing zeros can't be distinguished from measured precision. Measured trailing zeros count as insignificant: Parse("1.20") has 2 sig figs, so 1.20 × 1.23456 = 1.5 and 9.81 × 10.0 = 100 #120 only describes Parse with * and /, though. The addition symptom on integer conversions, and the fact that this is a regression introduced by Round sums and differences to tens and hundreds when an operand is that coarse #119, are not filed.
• Add/Subtract never round to tens or hundreds: 1.2E3 + 34 = 1234 instead of 1.2E3 #107 (closed) is the rule that Round sums and differences to tens and hundreds when an operand is that coarse #119 implemented. That rule is correct for genuinely coarse values such as Parse("1.2E3"); the problem is that it now also applies to exact integers.

Suggested fix

The full fix is the separate precision tracking proposed in #120. Until that lands, one of these:

• Treat values from integer conversions (int/long/... ToSignificantNumber(), CreateChecked from integer types) as exact to the units place, i.e. clamp CountDecimalDigits to ≥ 0 for them. Only an explicit coarse input, such as Parse("1.2E3"), would then round to tens or hundreds.
• Or revert the negative decimal places from Round sums and differences to tens and hundreds when an operand is that coarse #119 until precision can be tracked.

Acceptance criteria

• 10.ToSignificantNumber() + 2.ToSignificantNumber() == 12, 100 + 25 == 125, 20 - 3 == 17.
• Adding 2 ten times starting from Zero gives 20.
• The Add/Subtract never round to tens or hundreds: 1.2E3 + 34 = 1234 instead of 1.2E3 #107 behaviour for explicitly coarse values still holds: Parse("1.2E3") + 34 == 1.2E3.