[ttl] TTL can report success after deleting an unscanned row when a key column name is reused

## Bug Report

### 1. Minimal reproduce step (Required)

**Environment**

TiDB master 05b396fb66; one TiDB/PD/real TiKV; MDL ON; TTL enabled

**Steps**

On a TTL table, let a job scan one expired row and pause before delete SQL construction. Insert a second expired row, rename the original primary-key column, and rename another column to the old key name. Release delete and inspect row provenance plus mysql.tidb_ttl_table_status. The exact RED/control probe is scaffolds/top-level/ai_native_ttl_keyname_reuse_probe.sh.

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

A stale TTL task must abort when the key-column binding used by its scan snapshot changes. A row created after the scan must not be deleted by that task.

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

With MDL ON and the table ID unchanged, the TTL summary was total_rows=1, success_rows=1, error_rows=0. The post-scan row disappeared and the scanned row remained.

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

TiDB master 05b396fb66; one TiDB/PD/real TiKV; MDL ON; TTL enabled

Likely root cause and fix direction

**Likely root cause**

The scan task retains old PhysicalTable metadata and key values. BuildDeleteSQL later writes the old key-column name into an IN predicate. validateTTLWork checks table and physical IDs, TTL enablement, time-column name, and interval, but omits key-column ID/name bindings. Legal name reuse therefore rebinds the stale predicate to another column.

**Fix direction**

Reject key-column count, ID, name, order, or encoding-relevant type changes before accepting queued TTL work. The same-transaction validation must force rollback; validation before SQL construction can also avoid issuing stale DML.

Start by running scaffolds/top-level/ai_native_ttl_keyname_reuse_probe.sh to reproduce the stale-task behavior. Then trace validateTTLWork and BuildDeleteSQL, focusing on the key-column bindings retained by the scan task. Done means the stale task aborts after key-column changes, the post-scan row remains, and TTL status does not report success.

Written by the indexing model from the issue text.