Statement summary history does not prune time ranges for prepared FROM_UNIXTIME parameters

Bug Report

1. Minimal reproduce step (Required)

With persistent statement summary enabled and multiple rotated history files, execute Dashboard's bound time-overlap query with prepared plan cache enabled:

SET time_zone = '+00:00';
SET tidb_enable_prepared_plan_cache = 1;
PREPARE stmt FROM 'SELECT digest, SUM(exec_count) FROM information_schema.statements_summary_history WHERE summary_begin_time <= FROM_UNIXTIME(?) AND summary_end_time >= FROM_UNIXTIME(?) GROUP BY digest';
SET @end = 1577923200, @begin = 1577836800;
EXECUTE stmt USING @end, @begin;

Inspect the actual SELECT execution plan's StatementsSummaryExtractor.CoarseTimeRange. A prepared EXPLAIN is not a valid substitute: it can extract the range while the actual prepared SELECT cannot.

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

Extract the bound 2020-01-01–2020-01-02 overlap range and skip scans/full JSON decoding of unrelated persisted windows. Retain the exact SQL predicates and refresh the range on every execution.

3. What did you see instead (Required)

The real prepared SELECT has CoarseTimeRange == nil. FROM_UNIXTIME(?) is represented as a deferred constant, which the shared extraction helper rejects. Historical files are scanned even though scalar filtering eventually returns the correct rows. This increases synchronous work inside the customer's TiDB process when opening SQL Statements in Dashboard.

A new regression fails on the baseline with Expected value not to be nil. This is a performance issue, not a confirmed wrong-result issue. The finding relates to the Dashboard query path investigated under TCOC-2704; it does not establish the full cause or magnitude of the customer latency event.

4. What is your TiDB version? (Required)

Reproduced on current master at 12b639a116 (2026-09-30), using the repository testkit. The customer investigation mentions v7.5.6, which has not been validated with this new regression yet.