Which issue does this PR close?

• Closes Unsafe comparison cast rewriting in ExprSimplifier silently produces wrong query results #22142.

Rationale for this change

The previous cast-unwrap path could only move the original comparison operator
from CAST(expr AS target_type) OP literal to expr OP casted_literal. That is
not correct for many-to-one casts such as timestamp precision narrowing, where
the source-domain preimage of one target value is a range rather than a
singleton.

For example, CAST(ts_ns AS Timestamp(ms)) > 1000ms must not become
ts_ns > 1_000_000_000ns; its exact source boundary is
ts_ns >= 1_001_000_000ns.

Timestamp precision widening has a related ordered-comparison case. A
non-aligned target literal has no singleton equality preimage, but it does have
an exact source-unit boundary for an ordered predicate. For example:

CAST(ts_ms AS Timestamp(ns)) >= 123_456_789ns

becomes:

ts_ms >= 124ms

This PR also makes exact cast rewrites closed-by-default: exact rewrites require
a supported value-preserving cast family. Many-to-one or source-domain-reducing
casts either use an explicit range/boundary preimage or remain unchanged.

The ordered timestamp-widening rewrite deliberately follows the existing
widening policy used by this work. At extreme source values where widening
overflows, ordinary CAST can error and TRY_CAST can return NULL, while the
rewritten source-unit comparison returns a Boolean. This is not a claim of
full-domain equivalence for those overflow cases; a guarded/error-aware
preimage representation is outside this PR's scope.

What changes are included in this PR?

• Add a shared CastPredicatePreimage abstraction in
  datafusion-expr-common:
  • Exact(ScalarValue) for a same-operator source literal or boundary.
  • Range(Interval) for a half-open source-domain interval.
• Share cast-preimage computation between logical and physical simplifiers.
• Organize preimage computation into explicit range, special exact, generic
  exact, and ordered timestamp-widening paths.
• Implement timestamp precision narrowing preimages using half-open buckets
  with truncation-toward-zero semantics, including negative timestamps.
• Implement non-aligned ordered timestamp-widening boundaries using Euclidean
  floor/ceil arithmetic in i128:
  • >= L and < L use ceil(L / q).
  • > L and <= L use floor(L / q).
• Support all timestamp precision-widening unit pairs with matching timezone
  metadata, including CAST, TRY_CAST, and literal-left comparisons.
• Keep non-aligned equality, distinctness, and IN predicates unchanged.
• Keep timestamp precision narrowing out of IN rewrites because its preimage
  is a range rather than a singleton.
• Add conservative exact-cast family gates, including date, integer,
  signedness, decimal precision/scale, and canonical integer/string checks.
• Replace the logical optimizer's cast-unwrap module with a cast-preimage module
  and update the physical simplifier to use the same helper.

Behavior changes compared to main

Are these changes tested?

Yes. Tests cover:

• exact and range preimages and conservative cast-family gating,
• timestamp narrowing for positive, zero, and negative values,
• all timestamp widening unit pairs,
• aligned and non-aligned widening literals,
• all four ordered operators with positive and negative values,
• CAST, TRY_CAST, and literal-left forms,
• timezone/type/NULL rejection and i64 boundary literals,
• equality, distinctness, and IN remaining unchanged where required,
• logical, physical, and sqllogictest plan output.

Validated locally with:

cargo test -p datafusion-expr-common --lib cast_predicate
cargo test -p datafusion-optimizer --lib cast_preimage
cargo test -p datafusion-physical-expr --lib unwrap_cast
cargo test -p datafusion-sqllogictest --test sqllogictests -- simplify_expr
cargo fmt --all -- --check
cargo clippy --all-targets --all-features -- -D warnings

Are there any user-facing changes?

There are no public API changes. Optimized plans may now use exact source-domain
ranges or boundaries for cast predicates, and previously unsafe exact rewrites
may remain unchanged. Ordered timestamp-widening comparisons also follow the
explicit overflow policy described above.