planner/ranger: Teach getPotentialEqOrInColOffset the binary-collation exception for CAST(... AS BINARY) composite index suffix columns

## Summary

When a composite index (e.g., `(f, g)`) is used with a predicate like `f = CAST('a' AS BINARY) AND g = 1`, the suffix column `g` is incorrectly treated as a filter condition instead of an index range condition. This is because the EQ/IN prefix-extraction path in `ExtractEqAndInCondition` (specifically `getPotentialEqOrInColOffset` in `pkg/util/ranger/detacher.go`) still rejects columns with binary-casted literals due to incompatible collation checks — unlike the main detacher loop that was fixed in #67898 / #68389.

## Expected Behavior

For a composite index `(f, g)` and condition `f = CAST('a' AS BINARY) AND g = 1`, both `f` and `g` should be used for an `IndexRangeScan` (with a selection for correctness), not just `f`.

## Steps to Reproduce

See TODO comment added in #67898:
> The EQ/IN extraction path (ExtractEqAndInCondition, specifically getPotentialEqOrInColOffset) still rejects columns with binary-casted literals, which causes suffix index columns to be treated as filters. It should apply the same CAST(... AS BINARY) / collation-compatibility exception used in the detacher loop so binary-cast equality predicates are treated as index-equalities. Fix this in a later release and add a regression test for a composite index case (e.g., index on (f,g) with f = CAST('a' AS BINARY) AND g = 1).

## Fix

1. Update `getPotentialEqOrInColOffset` to apply the same `collate.IsBinCollation(collation)` exception that was added to `conditionChecker.checkScalarFunction` for `EQ`/`NullEQ`/`IN` cases.
2. Add a regression test for a composite index (e.g., `index on (f, g)`) with predicate `f = CAST('a' AS BINARY) AND g = 1` that verifies `IndexRangeScan` (not `IndexFullScan` + Selection) is produced.

## Related

- PR #67898 (original fix, master)
- PR #68389 (cherry-pick to release-8.5)
- Issue #67899

Reported by @terry1purcell.