🐛 Bug Report：GROUP_CONCAT without explicit SEPARATOR clause generates incorrect column name

## Bug Report

Please answer these questions before submitting your issue. Thanks!

### 1. Minimal reproduce step (Required)
```sql
CREATE TABLE t (c1 INT);
INSERT INTO t VALUES (1016), (1017), (1018);
SELECT GROUP_CONCAT(c1) FROM t;
```

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

Expected the result column name to match MySQL's behavior:
GROUP_CONCAT(c1)
without any extra SEPARATOR clause in the column name.

- Expected
```sql
mysql> SELECT GROUP_CONCAT(c1) FROM t;
+------------------+
| GROUP_CONCAT(c1) |
+------------------+
| A,A,B,A,B,B,C |
+------------------+
1 row in set (0.008 sec)
```

- Actual

```sql
+--------------------------------------+
| GROUP_CONCAT(c1 SEPARATOR ',') | # Incorrect column name
+--------------------------------------+
| 1016,1017,1018 |
+--------------------------------------+
```

### 3. What did you see instead (Required)
Actual column name contains an unexpected SEPARATOR clause:
GROUP_CONCAT(c1 SEPARATOR ',')
Result display:
```sql
+--------------------------------------+
| GROUP_CONCAT(c1 SEPARATOR ',') | # Incorrect column name
+--------------------------------------+
| 1016,1017,1018 |
+--------------------------------------+
```

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

tidb v8.5.2

### Additional Context (Recommended)

Affected Components:

- SQL parser
- SQL restoration logic
- Result metadata handling

Reproduce the query using GROUP_CONCAT(c1) on TiDB v8.5.2, then trace the SQL parser, SQL restoration logic, and result metadata handling identified in the report. Done means the result column name is GROUP_CONCAT(c1), without an implicit SEPARATOR clause, while the concatenated values remain correct.

Written by the indexing model from the issue text.