fix: do not derive ordering for arithmetic that can overflow

[buraksenn]

Which issue does this PR close?

• Closes sort should not be removed when order by a + b where a and b are sorted as they can overflow and wrap #23902.

Rationale for this change

Please check the issue for details but the main idea is that a + b over two
sorted columns is not guaranteed to be sorted.

What changes are included in this PR?

Ordering is discarded when it overflows or wraps

Are these changes tested?

Yes, adjusted existing tests and added a regression test in order.slt.

Are there any user-facing changes?

no api changes

[rluvaton]

@buraksenn Can you please mention the devs that added those test cases in the first place for review?

[codecov-commenter]

Codecov Report

❌ Patch coverage is 80.66298% with 35 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.88%. Comparing base (74eebbb) to head (d31efba).
⚠️ Report is 66 commits behind head on main.

Files with missing lines	Patch %	Lines
datafusion/physical-expr/src/expressions/binary.rs	77.98%	2 Missing and 33 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #23910      +/-   ##
==========================================
+ Coverage   80.70%   80.88%   +0.18%     
==========================================
  Files        1095     1102       +7     
  Lines      372554   376216    +3662     
  Branches   372554   376216    +3662     
==========================================
+ Hits       300661   304310    +3649     
+ Misses      53924    53763     -161     
- Partials    17969    18143     +174     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[buraksenn]

@buraksenn Can you please mention the devs that added those test cases in the first place for review?

@mustafasrepo @berkaysynnada @geoffreyclaude can you take a look at this PR if you've time?

[kosiew]

@buraksenn
Nice fix. The new invariant makes sense: arithmetic orderings are only preserved when overflow cannot happen or when overflow is configured to fail. The updates across the optimizer, tests, and sqllogictests look consistent. I just have a couple of small suggestions that could make the coverage a bit stronger.

[kosiew]

Nice focused regression test. One small suggestion: could we also add a couple of Minus cases covering signed minimum and unsigned underflow boundaries? The implementation now guards both Plus and Minus, but this test only exercises addition. It would help protect the subtraction path from future regressions.

[buraksenn]

I've added signed minimum and underflow boundaries which resulted into finding a gap. Resolved that as well thanks for finding this

[kosiew]

I wonder if we could narrow this exemption to only the specific arithmetic ordering that may be conservatively rejected. Using any means we skip the rejection assertion for the entire multi-key requirement whenever one key contains + or -, which reduces coverage for any later non-arithmetic keys. Not blocking, since it does not affect production behavior.

[buraksenn]

Thanks I've applied this as well

[kosiew]

@buraksenn, thanks for the follow-up changes.

The subtraction ordering regression coverage now includes signed-minimum overflow, unsigned underflow, safe bounded ranges, and time-minus-interval wrapping. The bounded unsigned subtraction logic also correctly compares the minimum left-hand endpoint with the maximum right-hand endpoint, which avoids deriving ordering guarantees when subtraction could underflow and wrap.

The fuzz-test exemption is now limited to the arithmetic-free ordering prefix in both the direct-ordering and projection tests, while still checking preceding non-arithmetic keys.

I did not find any new issues in the updated changes.