[expression] TiKV HashAgg ignores BINARY cast collation and silently merges distinct groups

## Bug Report

### 1. Minimal reproduce step (Required)

**Environment**

current master 05b396fb + real TiKV; default SQL mode; MDL ON

**Steps**

CREATE TABLE t(id INT PRIMARY KEY, v TEXT); INSERT INTO t VALUES (1,'') ,(2,' '),(3,'a'),(4,'A'),(5,'a '); SELECT BINARY v,COUNT(*) FROM t GROUP BY BINARY v ORDER BY 1;

### 2. What did you expect to see? (Required)

Five groups, each with COUNT(*) = 1.

### 3. What did you see instead? (Required)

With TiKV partial HashAgg the query returns two groups: empty/count 2 and a/count 3. A non-mergeable derived-table root oracle returns five groups.

### 4. What is your TiDB version? (Required)

current master 05b396fb + real TiKV; default SQL mode; MDL ON

Likely root cause and fix direction

**Likely root cause**

String CAST construction derives connection collation even when the target charset/collation is binary. During ExprToPB, that derived collation overwrites the binary RetType, so TiKV HashAgg groups using the connection collation.

**Fix direction**

Preserve the target binary charset/collation in newBaseBuiltinCastFunc4String; local counterfactual changes binary targets to use their target collation and restores five groups while keeping HashAgg pushed down.

Reproduce the issue with the provided CREATE, INSERT, and GROUP BY BINARY query using real TiKV, then inspect newBaseBuiltinCastFunc4String and the ExprToPB path. Verify how the binary target charset/collation is preserved for TiKV HashAgg. Done means the pushed-down query returns five groups with COUNT(*) = 1, while the derived-table oracle remains consistent.

Written by the indexing model from the issue text.