[Bug]: max_error_count is ignored and SHOW WARNINGS always retains 64 records

## Description

MatrixOne exposes the `max_error_count` session variable but does not use it to size the diagnostics retained for `SHOW WARNINGS`. The session keeps exactly 64 records regardless of whether `max_error_count` is smaller or larger.

## Environment

- Branch: `main`
- Commit: `e7d46d6dfb27696211ca828c55e245d3bd1b634d`
- Deployment: reproduced on local standalone and local 2-CN / 1-TN / 1-LogService
- Oracle: MySQL 8.3.0

## Steps to reproduce

```sql
create table src (g int, id int, v varchar(8), primary key (g,id));
-- Populate 100 groups, each with (id=1,'aa') and (id=2,'bbb').

set session group_concat_max_len = 4;

set session max_error_count = 10;
select count(*), sum(length(gc)) from (
select g, group_concat(v order by id separator '|') gc
from src group by g
) q;
show warnings;

set session max_error_count = 128;
select count(*), sum(length(gc)) from (
select g, group_concat(v order by id separator '|') gc
from src group by g
) q;
show warnings;
```

All 100 groups truncate and the aggregate control result is `100,400`.

## Actual behavior

MatrixOne returns exactly 64 warning records after each query:

- `max_error_count=10`: 64 records instead of 10.
- `max_error_count=128`: 64 records instead of 100.

The same fixed cap occurs under a forced `AP QUERY PLAN ON MULTICN` with 100,000 truncating groups. Both CN coordinators retain 64 records.

## Expected behavior

MySQL 8.3.0 retains up to the configured limit:

- `max_error_count=10`: 10 records.
- `max_error_count=128`: all 100 records.
- With the default `1024` and 100,000 truncating groups: 1024 records.

`SHOW WARNINGS` in MatrixOne should honor the active session value instead of a fixed implementation constant.

## Stability and controls

- Minimal 100-group reproducer: 3/3 on MatrixOne and MySQL; each product's output SHA-256 was identical across runs.
- MatrixOne standalone and 2-CN results use the same fixed 64-record cap.
- Aggregate values and the total number of groups are correct.
- A subsequent non-truncating statement clears the stored warnings.

## Evidence

- Minimal reproducer: `evidence/group_concat/group_concat_warning_retention.sql`
- MatrixOne output SHA-256: `bcbc8bac985364f83d63e42012616bb32838e77b0d3fa98d603e31b19b8b1eb6`
- MySQL output SHA-256: `d682cb5fef8d35b7c4457eccdd9073ce3df1b3469f136dc007bd992a94213d4a`
- Multi-CN 100,000-group output SHA-256 on both coordinators: `b9720a64717e30f3b71ca633d9b9d1fca04b3de63170a6badcdc11266501d679`

## Code analysis

Two fixed caps bypass the system variable:

- `pkg/frontend/session.go` initializes `errInfo.maxCnt` with `MoDefaultErrorCount`, which is hard-coded to 64. No session-variable update connects `max_error_count` to this field.
- `pkg/sql/colexec/aggexec/concat2.go` independently limits retained `GROUP_CONCAT` diagnostic rows with `groupConcatWarningRetentionLimit = 64` before publishing the exact total to the session.

This explains why lowering the variable to 10 does not reduce storage and raising it to 128 does not increase storage.

## Regression coverage

After the fix, execute a statement producing more warnings than the configured limit and assert exact `SHOW WARNINGS` record counts for `0`, `1`, `10`, `64`, `128`, and the default. Include local and remote warning-batch paths and restore the session setting afterward.

## Related

- #28252 implemented `GROUP_CONCAT` warning 1260 emission but does not cover configurable warning retention.
- #28665 covers incorrect `Row N` diagnostics, not the number of retained records.