`satisfy_greater` panics at composite interval component boundaries

[benbellick]

Describe the bug

satisfy_greater panics when strict inequality propagation needs the successor or predecessor of a valid IntervalDayTime or IntervalMonthDayNano value whose smallest component is at its numeric boundary.

The Arrow format represents IntervalDayTime as two signed 32-bit integers, and Arrow Rust accepts any i32 value for each component without normalization. Therefore, (0, i32::MAX) is a valid representation.

The adjacent-value implementation increments or decrements only the smallest component. satisfy_greater calls it directly, resulting in an IntervalDayTime overflow panic.

To Reproduce

use datafusion_common::{
    arrow::datatypes::IntervalDayTime,
    ScalarValue,
};
use datafusion_expr_common::interval_arithmetic::{
    satisfy_greater,
    Interval,
};

fn scalar(days: i32, milliseconds: i32) -> ScalarValue {
    ScalarValue::IntervalDayTime(Some(IntervalDayTime::new(
        days,
        milliseconds,
    )))
}

fn main() -> datafusion_common::Result<()> {
    let left =
        Interval::try_new(scalar(0, i32::MIN), scalar(1, i32::MAX))?;
    let right =
        Interval::try_new(scalar(0, i32::MAX), scalar(1, i32::MAX))?;

    satisfy_greater(&left, &right, true); // This panics.

    Ok(())
}

The process panics with:

IntervalDayTime overflow

Expected behavior

satisfy_greater should return a Result rather than panic. The implementation could handle component boundaries or return an error when an adjacent value cannot be computed.

IntervalMonthDayNano has the analogous problem at nanosecond and day boundaries.

Additional context

Found while investigating #25344.

Interval-typed expressions are currently excluded from physical constraint propagation, so this is reproducible through the public Rust API rather than an SQL query.