[executor] COM_STMT_PREPARE dedup can keep stale-read semantics after tidb_read_staleness is cleared

## Bug Report

> Evidence status: confirmed.

### 1. Minimal reproduce step (Required)

On one physical connection enable tidb_enable_cache_prepare_stmt, create t(id,v), insert (1,1), wait until that version is older than one second, set tidb_read_staleness=-1, prepare and execute SELECT v FROM t WHERE id=1 through COM_STMT_PREPARE, clear tidb_read_staleness, update v=2, then prepare and execute the identical SELECT again. Compare with the same SQL after disabling only tidb_enable_cache_prepare_stmt.

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

Clearing tidb_read_staleness must make subsequent newly prepared reads use current data; both executions after the update should return 2.

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

On testbed 8220955 the dedup-on prepared statement returned 1 while the identical SQL with dedup disabled returned 2. Local current-source execution produced the same RED. Replacing only the cached evaluator with the fresh Preprocess evaluator made the matrix GREEN.

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

current master 13282a8bd06b and testbed 8220955 version 5c9198e948

Likely root cause and fix direction

PrepareDedupCacheKey does not bind ReadStaleness or its derived snapshot evaluator. rebuildFromPrepareCache runs fresh Preprocess but discards ret.SnapshotTSEvaluator and copies cached.Stmt.SnapshotTSEvaluator, which captured the previous -1 second stale-read duration.

Start by locating PrepareDedupCacheKey and rebuildFromPrepareCache in the executor path for COM_STMT_PREPARE, then reproduce the dedup-on and dedup-off matrix from the report. Compare the fresh Preprocess evaluator with the cached statement evaluator after tidb_read_staleness is cleared. Done means both executions after the update return 2 with prepared-statement deduplication enabled.

Written by the indexing model from the issue text.