fix: preserve operand width in DecimalValue checked arithmetic

[abnobdoss]

Summary

Closes: #7022

DecimalValue::checked_add/sub/mul/div unconditionally upcast both operands to i256 and returned DecimalValue::I256, producing unnecessarily wide scalars even when both inputs were narrow (e.g. I32 + I32 → I256).

Operate at max(self, other) width instead, matching the pattern in aggregate_fn/fns/sum/decimal.rs. The old checked_binary_op helper was replaced with a local macro so each op dispatches with its own trait.

AI disclosure: Analysis, implementation, and tests were done with Claude Code under my direction and review.

API Changes

No public API signature changes (verified via ./scripts/public-api.sh).

Overflow is now caught at the target width rather than silently widening (e.g. I8(i8::MAX) + I8(1) now returns None instead of I256(128)). This felt like the most faithful reading of the issue, but I'd appreciate a sanity check that returning None on target-width overflow is the desired semantics rather than, say, promoting to the next wider variant. No in-tree caller depends on the old behavior: sum/mod.rs pre-widens the accumulator by +10 precision, decimal/scalar.rs::checked_binary_numeric requires both operands to share the same width, and sum/constant.rs uses I128 as the multiplier.

Testing

• Updated test_decimal_value_checked_* to assert the correct variant.
• Added tests for variant preservation, mixed-width promotion, and overflow at the target width (including i8::MIN / -1).
• All existing tests pass (212 decimal, 14 sum).

[joseph-isaacs]

I256 is not the maximum of the inputs. I would accept a PR doing this