date_trunc array fast path underflows for extreme timestamps #25129

Describe the bug

date_trunc can underflow when its array fast path truncates an extreme timestamp. In debug builds, the unchecked subtraction can panic. In release builds, it can wrap and return an incorrect timestamp.

The scalar path handles out-of-range arithmetic by returning a DataFusion error, but general_date_trunc_array_fine_granularity performs the truncation with unchecked arithmetic:

*v - i64::rem_euclid(*v, unit)

This was identified while reviewing #24501. The optimizer proposed there evaluates scalar boundary values, while normal query execution uses the array path. These paths should have consistent overflow behavior before date_trunc is used to establish partitioning guarantees.

To Reproduce

CREATE TABLE extreme_times AS
SELECT arrow_cast(value, 'Timestamp(Nanosecond, None)') AS ts
FROM (VALUES (-9223372036854775807 - 1)) AS t(value);

SELECT ts, date_trunc('microsecond', ts) AS truncated
FROM extreme_times;

DataFusion fiddle

On DataFusion CLI 54.1.0 in a release build, this returns:

+-------------------------------+-------------------------------+
| ts                            | truncated                     |
+-------------------------------+-------------------------------+
| 1677-09-21T00:12:43.145224192 | 2262-04-11T23:47:16.854775616 |
+-------------------------------+-------------------------------+

Truncating the year 1677 timestamp should not produce a timestamp in 2262.

Expected behavior

Return a DataFusion error when the truncated timestamp cannot be represented by the timestamp's underlying i64, rather than panicking or wrapping.

The array path should behave consistently with the checked scalar path.

Additional context

• Identified during review of feat: skip hash shuffle for date_bin/date_trunc on Range([timestamp]) #24501.
• Related to panic: date_trunc overflows converting extreme non-ns timestamps to nanoseconds #22209, which fixed a different date_trunc overflow when scaling extreme non-nanosecond scalar timestamps to nanoseconds.
• date_part returning wrong results due to overflows #14738 concerns overflow in date_part and is a separate code path.