fix(stats): widen sum_value integer arithmetic to SUM-compatible types

[kumarUjjawal]

Which issue does this PR close?

• ClosesMatch Precision sum function against Int64 to prevent overflow. #20826.

Rationale for this change

As discussed in the review thread on #20768 and tracked by #20826, sum_value should not keep narrow integer column types during stats aggregation, because merge/multiply paths can overflow before values are widened.

What changes are included in this PR?

This PR updates statistics sum_value arithmetic to match SUM-style widening for small integer types, and applies that behavior consistently across merge and multiplication paths.

Are these changes tested?

Yes

Are there any user-facing changes?

[kumarUjjawal]

cc @jonathanc-n

[Dandandan]

I think this looks good @jonathanc-n can you take a look as well?

[jonathanc-n]

Lgtm thanks!

[asolimando]

Thanks for working on this @kumarUjjawal, but I have a few suggestions:

1. The original idea in Match Precision sum function against Int64 to prevent overflow. #20826 was to change the sum_value field type to always store a wide type, making overflow protection structural. The lazy-widening approach here requires every future call site to remember to use add_for_sum/cast_to_sum_type instead of add/multiply, with no compiler enforcement. At minimum, a doc comment on sum_value warning about this would help.

This forces to change all consumers, but it would prove more robust over time.

2. The Exact/Inexact arms in cast_to_sum_type are nearly identical and could be collapsed I think

[Dandandan]

@kumarUjjawal can you fix CI?

[kumarUjjawal]

@Dandandan Done!

[asolimando]

LGMT, the PR is hardening as much as possible for a non-breaking change, improving over the current situation

[kumarUjjawal]

@asolimando Thanks for the review!

[kumarUjjawal]

@alamb this is good to go.

[alamb]

Thanks @kumarUjjawal and @Dandandan