[ABA-24] test(vortex-array): repro for decimal-array arithmetic dispatch rejection

[abnobdoss]

Summary

• Feature gap, not a regression. Binary::return_dtype at vortex-array/src/scalar_fn/fns/binary/mod.rs:119-128 gates all arithmetic on lhs.is_primitive(). DType::Decimal(..) is never primitive, so every arithmetic call on decimal arrays — even same-precision, same-scale, no-null add/sub/mul/div — bails out before any kernel is invoked. There is no decimal arithmetic kernel in scalar_fn::fns.
• Adds one #[ignore]'d test (issue_aba24_decimal_array_add_same_scale_must_succeed) that reproduces the exact error (incompatible types for arithmetic operation: decimal(5,2) decimal(5,2)) and will flip to passing once the missing kernel lands.
• Repro-only commit — no production code changed.

Test verification

# Correctly ignored (skipped) by default:
cargo test -p vortex-array --lib -- scalar_fn::fns::binary::tests::issue_aba24
# running 1 test … ignored

# Correctly fails when un-ignored:
cargo test -p vortex-array --lib -- scalar_fn::fns::binary::tests::issue_aba24 --ignored
# FAILED: Error: Other error: incompatible types for arithmetic operation: decimal(5,2) decimal(5,2)

Open questions for reviewers

1. Kernel home: Should decimal arithmetic kernels live in scalar_fn::fns::binary alongside primitive, or be lifted to a separate dispatcher (e.g. a decimal sub-module with its own execute_decimal)?
2. Scale-mismatch policy: Same-scale add/sub can be done lane-wise (raw integer add, dtype preserved). Mul necessarily widens scale (s_out = s_lhs + s_rhs). Div is the hardest (precision loss, rounding). Should the first kernel target only same-scale add/sub, with mul/div deferred?
3. Overflow semantics: For large-precision decimals (i128, i256 backing), overflow on add can exceed the declared precision. Should the kernel check and bail, or silently wrap?

Linear

https://linear.app/abanoubdoss/issue/ABA-24

---

🤖 Generated with Claude Code