TiDB does not eliminate duplicate `GROUP BY` expressions, causing a measurable slowdown

## Bug Report

Please answer these questions before submitting your issue. Thanks!
The original query and the mutated query are logically equivalent. The only difference is that the mutated query adds a duplicate expression to the `GROUP BY` list.

TiDB v8.5.7 keeps the duplicated grouping key in the execution plan instead of removing it. That makes aggregation work more expensive, and the mutated query is consistently slower in local reruns.

Observed timing over 30 alternating executions with the minimized SQL:

```text
original median = 16.546 ms
mutated median = 27.604 ms
ratio = 1.6684x slower
```

### 1. Minimal reproduce step (Required)

```sql
DROP DATABASE IF EXISTS tidb_gb_min;
CREATE DATABASE tidb_gb_min;
USE tidb_gb_min;

CREATE TABLE t (
c1 INT NOT NULL,
c6 MEDIUMTEXT NOT NULL
);

INSERT INTO t VALUES (8945, REPEAT('a', 734));

-- Original query
SELECT COUNT(*)
FROM t
GROUP BY REPEAT(c6, c1);

-- Mutated query: duplicate GROUP BY expression
SELECT COUNT(*)
FROM t
GROUP BY REPEAT(c6, c1), REPEAT(c6, c1);

-- Optional: inspect the plan difference
EXPLAIN
SELECT COUNT(*)
FROM t
GROUP BY REPEAT(c6, c1);

EXPLAIN
SELECT COUNT(*)
FROM t
GROUP BY REPEAT(c6, c1), REPEAT(c6, c1);
```

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

Both queries should produce the same result and similar execution time.
### 3. What did you see instead (Required)
Original plan:

```text
HashAgg_5
group by:Column#5
```

Mutated plan:

```text
HashAgg_5
group by:Column#5, Column#5
```

The duplicate grouping key is preserved in the mutated plan.

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

```text
Release Version: v8.5.7
Edition: Community
Git Commit Hash: 202b7f47286a1109b5c957401d34c9358d130ae0
Git Branch: HEAD
UTC Build Time: 2026-07-15 02:06:00
GoVersion: go1.25.10
Race Enabled: false
Check Table Before Drop: false
Store: unistore
```

Start by running the minimized SQL and both EXPLAIN statements from the issue on TiDB v8.5.7, comparing the original and duplicated GROUP BY plans. Trace the planner or aggregation path that retains the duplicate grouping expression. Done means the mutated query no longer shows the duplicate grouping key and the supplied reproduction is covered by a regression test.

Written by the indexing model from the issue text.