[flink] Fix BETWEEN literal extraction in PredicateConverter

[WenDing-Y]

Summary

Fix PredicateConverter handling of Flink BETWEEN so lower/upper bounds are real Java literals instead of unextracted ValueLiteralExpression nodes.

fix #4000

Previously the converter did:

builder.between(idx, children.get(1), children.get(2));

which stored Flink AST nodes as predicate literals. That made toString()-based assertions pass (because ValueLiteralExpression.toString() looks like "10"), while predicate.test(row) failed at runtime (Unsupported type: BIGINT in CompareUtils.compareLiteral).

This change extracts both bounds via extractLiteral(...), consistent with EQUALS / IN / LIKE, and adds a row-evaluation test that would have caught the bug.

Changes

• PredicateConverter: extract BETWEEN lower/upper bounds with extractLiteral before calling builder.between.
• PredicateConverterTest:
  • add testBetweenEvaluatesAgainstRow (predicate.test(GenericRow...))
  • align parameterized expected bounds to 10L / 20L (BIGINT field + literal cast)

Why the old test passed

The parameterized case only compared:

converter.visit(BETWEEN).toString()
  ==
BUILDER.between(...).toString()

Both printed as something like:

And([GreaterOrEqual(long1, 10), LessOrEqual(long1, 20)])

even though one side held ValueLiteralExpression objects and the other held numeric literals. String equality hid the type mismatch.

Test plan

• ./mvnw -pl fluss-flink/fluss-flink-common -am test -Dtest=PredicateConverterTest
• Confirm testBetweenEvaluatesAgainstRow fails on the unfixed code and passes after the fix

[WenDing-Y]

@wuchong

[WenDing-Y]

@fresh-borzoni