Why I'm doing:

Currently, there is no support for date/string type casting in IN expressions.

What I'm doing:

Implement multi-value conversion for IN expressions using equality-based logic.

Fixes #issue

What type of PR is this:

[ ] BugFix
[ ] Feature
[x] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[x] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)
- [ ] I have added documentation for my new feature or new function
[ ] This is a backport pr

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch
- [x] 3.5
- [ ] 3.4
- [ ] 3.3

[!NOTE] Adjust IN type compatibility to use binary rules for consistent date↔string casting; add unit test validating date/string IN behavior.

Type resolution:

Update TypeManager.getCompatibleTypeForBetweenAndIn(...) to short-circuit for IN when RHS types are uniform, delegating to getCompatibleTypeForBinary(false, ...) to ensure proper date↔string compatibility (e.g., datetime string vs date values).

Tests:

Extend ImplicitCastRuleTest.testInPredicate to cover datetime-string LHS with date RHS values, asserting casts are applied to all operands.

^{Written by Cursor Bugbot for commit 5a2221bf9af269e358ab94739ef9267eb5297e0f. This will update automatically on new commits. Configure here.}