[Bug]: cn-dev system.statement_info marker/time-window diagnostics time out

## Description

In the cn-dev MatrixOne environment, bounded diagnostic queries against `system.statement_info` for one AP-regression run all time out at the MySQL client layer. The table is available and its schema can be read, but the four read-only diagnostic queries do not return before the client read timeout.

This is being filed separately from #26960 and #24872. Those issues had different original environments and query shapes; their later single-CN regression checks do not cover this cn-dev multi-CN marker-and-time-window workload.

## Environment

- Environment: cn-dev, serverless dev tenant
- MatrixOne version: `8.0.30-MatrixOne-v4.2.0`
- Topology: cn-dev multi-CN environment
- Regression workflow commit: `e1ed977f20306725834f8980d4743b7d003d8185`
- Observed window: `2026-09-11 03:53:02` to `2026-09-14 19:27:28` UTC

## Steps to reproduce

1. Run the dev AP regression with a unique marker embedded in statements, for example `dev-ap::`.
2. Query `system.statement_info` using both that marker and the run time window.
3. Run these read-only shapes (each has the same marker + `request_at` range predicate):
- aggregate status summary with `COUNT`, `MIN`, `MAX`, and `GROUP BY status`;
- failed statement list ordered by `request_at` with `LIMIT 200`;
- long-running statement list ordered by `duration` with `LIMIT 200`;
- active statement list ordered by `request_at` with `LIMIT 200`.

## Actual behavior

All four queries failed with the same client-visible error:

```text
(2013, 'Lost connection to MySQL server during query (The read operation timed out)')
```

`SHOW COLUMNS FROM system.statement_info` succeeded immediately before the queries, so this is not a missing table or authentication failure. The diagnostics could not retrieve a summary or any records.

## Expected behavior

Read-only, marker- and time-bounded diagnostic queries should complete and return the matching rows or an empty result. A diagnostic query must not terminate its MySQL connection due to a server-side/nonresponsive execution path.

## Stability and controls

- Observed once in the completed AP regression workflow linked below.
- Control: `SHOW COLUMNS FROM system.statement_info` succeeded in the same diagnostic invocation.
- The current evidence does **not** yet satisfy a 3/3 reproduction on official `main`; this cn-dev observation is submitted for triage and to preserve the failure evidence.

## Evidence

- Workflow run: https://github.com/matrixorigin/mo-nightly-regression/actions/runs/34560092451
- Failing diagnostics job: https://github.com/matrixorigin/mo-nightly-regression/actions/runs/34560092451/job/104119214980
- Artifact: `ap-regression-dev-statement-info-34560092451`, containing the redacted `statement-info.json` and `statement-info.md`.

## Related

- #26960 — historical `statement_info` performance issue; different original environment and workload.
- #24872 — historical `statement_info` stuck-query/CN-draining issue; different original environment and workload.