fix: preserve timestamp precision when coercing mixed time units

[fengys1996]

Which issue does this PR close?

• Closes Incorrect timestamp comparison with mixed time units #22756.

Rationale for this change

DataFusion coerced Timestamp values with different TimeUnits to the coarser unit which result in a loss of precision and lead to incorrect comparison semantics

What changes are included in this PR?

• Change timestamp time unit coercion to prefer the finer unit.
• Add overflow checks for timestamp-to-timestamp casts when converting to a finer unit.

Are these changes tested?

Yes. Added unit tests for timestamp coercion and overflow checks, plus sqllogictest coverage for comparison, subtraction, UNION, and COALESCE.

Are there any user-facing changes?

Yes. Timestamp operations with mixed time units now coerce to the finer unit. If that conversion would overflow i64, the query returns an overflow error.

[fengys1996]

@alamb ptal if you have time! Thank you.

[Jefffrey]

is this similar to

• fix: replace default-allow cast unwrap with closed-by-default allowlist (timestamp + integer widening) #21908

[alamb]

is this similar to

• fix: replace default-allow cast unwrap with closed-by-default allowlist (timestamp + integer widening) #21908

I think they are related, but not quite the same. Specifically #21908 I think is for the unwrap in cast optimization (e.g. '2025-12-25' = CAST(column as date) and moving the cast to the constant

I think this is about coercing types when comparing across unions and comparisons

[alamb]

Makes sense to me -- thank you @fengys1996 and @Jefffrey

[alamb]

It might make sense to keep treating date and timestamp separately for consistency with the rest of the code. For example keep date_scalar_value_as_i64 and add timestamp_scalar_value_as_i64

But this looks fine too

[alamb]

here is an example where the old code would lose data (it would convert millisecond precision to second precision)