fix: use cast preimages for cast predicate rewrites

[discord9]

Which issue does this PR close?

• Related to TIMESTAMP predicate incorrectly matches rows with higher fractional seconds greptimedb#8214
• Upstream context: refactor: Use cast preimages for cast predicate rewrites apache/datafusion#22906, Incorrect timestamp comparison with mixed time units apache/datafusion#22756

Rationale for this change

GreptimeDB currently patches DataFusion crates from GreptimeTeam/datafusion at rev e8a127c28e8839964bb6aefdd909810dc11cd2c9, which is on branch greptimedb-53.1.0-function-signature-exec-error.

GreptimeDB can produce incorrect timestamp predicate results when a timestamp column is compared through a lower-precision cast, for example matching 2026-06-02 03:50:00.195 for a <= '2026-06-02 03:50:00' predicate.

The existing cast predicate rewrite can unwrap casts that are not one-to-one, changing predicate semantics for timestamp precision narrowing and other lossy casts. This ports the upstream Apache DataFusion cast-preimage fix onto the GreptimeDB-dependent DataFusion branch so predicate rewrites are only applied when the preimage is known to preserve semantics.

What changes are included in this PR?

• Introduce shared cast predicate preimage logic in datafusion-expr-common.
• Use exact preimages for safe cast predicate rewrites.
• Use range preimages for timestamp precision narrowing instead of unsafe exact cast unwrapping.
• Reject unsafe exact rewrites for numeric narrowing, lossy decimal casts, timestamp narrowing, and similar many-to-one casts.
• Share the safer logic between logical optimizer and physical expression simplifier.
• Add regression coverage for timestamp, decimal, distinctness, and edge-case cast predicate behavior.

Are these changes tested?

In progress locally after opening this PR.

Already checked before opening:

• cargo fmt --all was run; branch is formatted.

Planned next local checks:

• DataFusion Rust CI-equivalent cargo checks/tests/clippy that can be run locally for this branch.

Are there any user-facing changes?

Yes. Query results for predicates involving lossy casts become more correct and conservative: unsafe cast unwrapping is avoided, and timestamp precision narrowing is rewritten using ranges that preserve predicate semantics.