fix(query): refine infer filter type compatibility

[KKould]

I hereby agree to the terms of the CLA available at: https://docs.databend.com/dev/policies/cla/

Summary

• fixes: refactor: improve data type cast and compatibility check #17933
• Refine InferFilter equality inference so an equality edge must be safe for equivalence-class reasoning, not merely executable by Databend's eq function.
• Centralize the inference decision in safe_common_type: compute an inference-safe common type, then require both sides to cast to that type through injective/lossless-enough conversions.
• Allow inference through same-type equality for the scalar types currently covered by InferFilter, nullable wrappers, Null, integer-to-integer casts, integer-to-Decimal casts, Decimal widening, Date to Timestamp, Float-to-wider-Float, exact same Map types, and recursive Array/Tuple casts when their elements/fields are also safe.
• Keep signed/unsigned integer inference to preserve existing optimizer behavior, such as propagating constants across BIGINT = BIGINT UNSIGNED join keys.
• Reject mixed String equality, mixed Variant equality, mixed/empty Map equality, Number/Decimal to Float equality, and unsafe nested combinations so InferFilter does not derive predicates that are not implied by the original SQL.
• Types outside the explicit inference-safe set are left unchanged by this PR rather than being used as new equivalence-class edges without dedicated coverage.
• Keep inferred replacement predicates type-checkable, and add explicit coverage for String, Boolean, Date/Timestamp, Variant, Decimal, Float, arrays, tuples, maps, and nested equality-facing types.

Tips

The safe common type path intentionally avoids Databend's normal eq auto-cast and TRY_CAST rules. Those rules are valid for expression evaluation, but failed conversions can become NULL, so the comparison is not a safe equivalence relation for deriving transitive predicates.

String and numeric equality is intentionally rejected. For example, '01' = 1 and '1' = 1 can both evaluate to true, while '01' = '1' is false, so using those edges to infer '01' = '1' would be incorrect.

Float equality is intentionally not used as an inference edge when it requires converting an integer or Decimal into Float. Integer/Decimal values can collapse after conversion to Float, so the conversion is not injective/lossless enough for equivalence-class inference.

Tests

• Unit Test
• Logic Test
• Benchmark Test
• No Test - Explain why

Validation commands:

cargo fmt --check
git diff --check
cargo test -p databend-query --test it infer_filter
cargo build --bin databend-query --bin databend-sqllogictests
target/debug/databend-sqllogictests --handlers http --run 'tests/sqllogictests/suites/mode/standalone/explain/infer_filter.test'
target/debug/databend-sqllogictests --handlers http --run 'tests/sqllogictests/suites/mode/standalone/explain_native/infer_filter.test'

Type of change

• Bug Fix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Breaking Change (fix or feature that could cause existing functionality not to work as expected)
• Documentation Update
• Refactoring
• Performance Improvement
• Other (please describe):

---

This change is 

[sundy-li]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Already looking forward to the next diff.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".