*: fix statement summary history and display correctness

## Bug Report

### 1. Minimal reproduce step (Required)

On TiDB master before the fixes in this issue:

1. Query statement summary history with a single-sided predicate such as `SELECT * FROM information_schema.statements_summary_history WHERE summary_end_time >= '2020-01-01 00:00:00'`. The planner narrows the missing end boundary to one hour instead of keeping it open.
2. Create multiple statement-summary intervals and reduce `tidb_stmt_summary_history_size`. Read the history table. The reader keeps or returns the oldest intervals instead of the latest intervals. The same issue is present in the v1 `EVICTED` history reader.
3. Execute SELECT statements that collect KV/PD/backoff/write-response timing, then query `AVG_KV_TIME`, `AVG_PD_TIME`, `AVG_BACKOFF_TOTAL_TIME`, and `AVG_WRITE_SQL_RESP_TIME` from statement summary. These sums are per execution, but the v1 and v2 readers divide them by `COMMIT_COUNT`.
4. Use a statement context containing empty table entries around valid table entries and read `TABLE_NAMES`. The v1 and v2 builders append separators using the original slice index, which can leave a trailing comma.
5. Set `tidb_stmt_summary_max_sql_length` to a small value and query v2 `DIGEST_TEXT`. The v2 record stores the unbounded normalized SQL while v1 applies the configured truncation format.

Focused regression tests for these cases are included in the proposed fix under `pkg/util/stmtsummary` and `pkg/util/stmtsummary/v2`.

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

- Single-sided time predicates preserve their open boundary and return all matching history.
- History readers return the latest configured number of intervals in chronological order.
- Execution-based average columns use `EXEC_COUNT` as their denominator, including SELECT statements with no commits.
- `TABLE_NAMES` contains only valid table names separated by commas, without a trailing separator.
- v1 and v2 `DIGEST_TEXT` follow the same `tidb_stmt_summary_max_sql_length` truncation format.

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

The planner silently drops history outside an artificial one-hour window; history reads prefer stale intervals; execution averages can be reported as zero; `TABLE_NAMES` can contain a trailing comma; and v2 `DIGEST_TEXT` can exceed the configured maximum and disagree with v1.

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

TiDB master at the audited pre-fix baseline `0b84b155df1935401e2db4d2c28b833cae45c2f8`.

### Analysis

The defects are in the planner's coarse time-range construction and the v1/v2 statement-summary history, aggregation, and display factories. They are independent read-path correctness issues and can be fixed without changing the statement-summary storage format.

Start with the focused regression tests in pkg/util/stmtsummary and pkg/util/stmtsummary/v2, then trace the planner's time-range construction and the v1/v2 history, aggregation, and display factories. Done means open time boundaries and latest intervals are preserved, execution averages use EXEC_COUNT, table names have no trailing separator, and both DIGEST_TEXT paths honor the configured length.

Written by the indexing model from the issue text.