[python] Align FieldSumAgg with Java implementation

[PyRSA]

Purpose

This PR aligns the Python FieldSumAgg implementation with the Java implementation.

The changes include:

• Support aggregation and retraction for all numeric types.
• Add overflow checks for integral types (TINYINT, SMALLINT, INT, BIGINT).
• Support DECIMAL aggregation with precision and scale handling.
• Add comprehensive unit tests covering normal and overflow cases.

Dependency

This PR depends on #8718, which introduces the Python Decimal implementation and the numeric boundary constants used for overflow checking.

Tests

• python -m pytest pypaimon/tests/test_field_aggregators.py::FieldSumAggTest -q
• python -m pytest pypaimon/tests/test_aggregation_e2e.py -q
• python -m pytest pypaimon/tests/test_aggregation_merge_function.py -q
• git diff --check

[JingsongLi]

This is also affected by the shared Decimal implementation; a valid DECIMAL(38,0) sum operation will fail due to precision=28, and encoding/decoding of unscaled bytes with scale>18 will also fail.

[PyRSA]

This is also affected by the shared Decimal implementation; a valid DECIMAL(38,0) sum operation will fail due to precision=28, and encoding/decoding of unscaled bytes with scale>18 will also fail.

Fixed. This is resolved by the updates in the shared Decimal implementation (depends on #8718).

[JingsongLi]

Please resolve conflicts.

[PyRSA]

Please resolve conflicts.

Resolved, thanks!

[JingsongLi]

FieldSumAgg first performs Decimal addition outside the high-precision context, causing a valid DECIMAL(38,0) value to be truncated by Python's default 28-bit precision. The issue still occurs in the latest head: 12345678901234567890123456789012345678 + 1 actually returns 12345678901234567890123456790000000000, when the correct result should be .. .345679

[PyRSA]

FieldSumAgg first performs Decimal addition outside the high-precision context, causing a valid DECIMAL(38,0) value to be truncated by Python's default 28-bit precision. The issue still occurs in the latest head: 12345678901234567890123456789012345678 + 1 actually returns 12345678901234567890123456790000000000, when the correct result should be .. .345679

Thanks. Fixed！

[JingsongLi]

Same to #8718

[PyRSA]

Same to #8718

Thanks! This PR reuses the Decimal fixes from #8718, so #8718 needs to be merged first.

[JingsongLi]

+1