[fix](fe) Validate casts before constant folding

[Mryange]

Problem Summary: Constant folding evaluated literal casts before CheckCast validated whether the source and target types were compatible. As a result, an unsupported BIGINT to TIMESTAMPTZ cast could be folded into an incorrect timestamp literal, while the same cast on a column was rejected. This change reuses CheckCast in FE constant folding and leaves unsupported casts unchanged so the normal validation rule reports a consistent analysis error.

Release note

None

Check List (For Author)

• Test

  • Regression test
  • Unit Test
  • Manual test (add detailed scripts or steps below)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

• Behavior changed:

  • No.
  • Yes.

• Does this need documentation?

  • No.
  • Yes.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[Mryange]

/review

[github-actions]

Codex automated review failed and did not complete.

Error: This content was flagged for possible cybersecurity risk. If this seems wrong, try rephrasing your request. To get authorized for security work, join the Trusted Access for Cyber program: https://chatgpt.com/cyber
Workflow run: https://github.com/apache/doris/actions/runs/31804161206

Please inspect the workflow logs and rerun the review after the underlying issue is resolved.

[Mryange]

/review

[github-actions]

Automated review conclusion: changes requested.

The projected SELECT fix is directionally correct, but the stated goal of a consistent analysis error is not reached across all reachable plan shapes. The attached blocking finding shows that invalid constant casts can be discarded before CheckCast, while default fast INSERT ... VALUES never runs that validator.

Critical checkpoint conclusions:

• Goal and correctness: The guard fixes the ordinary FE-folded projection, and the added tests prove that local path, but the reachable ORDER BY, GROUP BY, and fast-insert paths leave the goal incomplete.
• Scope and conditional design: The patch is small and reuses the existing legality table, but returning a residual cast is only safe when every consumer is guaranteed to validate it; that invariant does not hold.
• Parallel paths and configuration: Strict/non-strict casting, TryCast, BE folding, fold-disabled execution, nested casts, and recursive complex casts were checked. The normal variants preserve the cast until validation; default fast values analysis is the surviving parallel-path gap. No new configuration was added.
• Tests and results: The unit checks and expected-error regression are coherent, but they omit the three concrete failing plan shapes in the inline finding. No local build or test was run, as required by the review runner. CI shows successful CheckStyle and general repository checks, but no relevant FE unit/regression result was present.
• Concurrency and lifecycle: Not involved; this is a stateless expression rewrite and introduces no lock, thread, resource, or initialization lifecycle.
• Compatibility and protocol: No function symbol, storage format, persisted state, or FE-BE variable/protocol change is introduced.
• Transactions and data writes: No transaction or persistence mechanism is changed. The fast-insert issue is validation timing before execution, not a new atomicity mechanism.
• Performance and observability: The legality lookup is bounded and no material performance issue was found; this analysis-time validation change does not require new logs or metrics.
• User focus: No additional user-provided focus was supplied.
• Other issues: No additional non-duplicate defect remained after three rounds; the final round converged.

[github-actions]

This early return relies on a later CheckCast, but validation currently happens after rules that can erase constant expressions. For example:

Sort(CAST(CAST(20240229112233 AS BIGINT) AS TIMESTAMPTZ(6)))

is processed by EliminateOrderByConstant before expression normalization; because the invalid deterministic cast is still isConstant(), the sort key is removed and CheckCast never sees it. Similarly, NormalizeAggregate.eliminateGroupByConstant folds a GROUP BY-only occurrence, treats the unchanged cast as constant, and removes it before validation. Thus the corresponding ORDER BY and GROUP BY queries can be accepted while the projected expression in the new regression errors. The default fast INSERT ... VALUES analyzer also invokes this folder without any CheckCast and skips normal rewrite, so that path fails only during BE execution. Please enforce cast legality before constant-expression elimination/translation, and add regressions for these paths.