[fix](constant folding) avoid folding non-comparable ordered literals

[Baymine]

What problem does this PR solve?

Issue Number: close #66829

Problem Summary:
The FE FoldConstantRuleOnFE visitors for the ordered comparisons
>, >=, <, <= unconditionally cast both operands to
ComparableLiteral before folding. When a child folds to a literal that
extends Literal but does not implement ComparableLiteral (for
example curtime() folding to TimeV2Literal), the cast throws a
java.lang.ClassCastException during planning, crashing queries such as
curtime() >= '20:00:00'.

Root cause: visitGreaterThan, visitGreaterThanEqual, visitLessThan,
and visitLessThanEqual perform the cast without first checking that
both children are ComparableLiteral, unlike the already-correct
visitEqualTo and visitNullSafeEqual visitors which guard with
instanceof ComparableLiteral.

Fix: guard each of the four ordered-comparison visitors with the same
instanceof ComparableLiteral check. When both operands are comparable
the fold proceeds as before; otherwise the original comparison
expression is returned unchanged so the predicate is preserved for later
evaluation instead of crashing at plan time.

Release note

Fix a ClassCastException in the Nereids FE constant-folding rule when an
ordered comparison (>, >=, <, <=) has an operand that folds to a
non-comparable literal such as a TIME value; the comparison is now kept
as a predicate instead of crashing planning.

Check List (For Author)

• Test: Unit Test
  • Added FoldConstantTest#testComparisonFoldWithNonComparableLiteral
    covering all four ordered operators (>, >=, <, <=) with
    TimeV2Literal, asserting the comparison stays un-folded and both
    children remain TimeV2Literal; verified red before the fix
    (ClassCastException) and green after. Full FoldConstantTest class
    passes (25 tests). FE checkstyle and FE build pass.
• Behavior changed: Yes. Previously an ordered comparison over a
  non-comparable folded literal threw a ClassCastException during
  planning; it is now preserved as a predicate and evaluated normally.
• Does this need documentation: No

[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?

[Baymine]

run buildall