[ddl] FLASHBACK CLUSTER can restore a cached table without its lock row and block all writes

## Bug Report

> Evidence status: confirmed.

### 1. Minimal reproduce step (Required)

```sql
Create and CACHE a non-partition table, record a transaction TSO, run NOCACHE and verify its table_cache_meta row is deleted, then FLASHBACK CLUSTER to that TSO. SHOW CREATE restores CACHED ON while the row remains absent. SELECT succeeds by fallback;
a fresh-session INSERT fails with table_cache_meta tid not exist.
```

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

A successful Flashback must either restore/rebuild every runtime owner required by restored metadata, or reject a window containing unsupported cache-state DDL. Normal DML must remain writable after completion.

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

On testbed 8220955, job 5432 synced/public and restored table ID 5428 as CACHED ON. table_cache_meta count stayed 0; SELECT returned (1,10), INSERT (2,20) returned ERROR 1105, and the rowset stayed unchanged. Replacing only the missing row made the same INSERT succeed.

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

current master 13282a8bd06b local consumer RED; testbed 8220955 commit 5c9198e948 SQL-only RED

Likely root cause and fix direction

getFlashbackKeyRanges restores user schema metadata and data but excludes mysql schema state. NOCACHE deletes mysql.table_cache_meta, while CACHE/NOCACHE are allowed by the Flashback DDL compatibility guard. The restored TableCacheStatusEnable therefore points to an absent mandatory lock row; cached-table DML propagates loadRow failure before commit.

Start by reproducing the FLASHBACK CLUSTER sequence with CACHE/NOCACHE and inspect getFlashbackKeyRanges alongside the mysql.table_cache_meta state. Compare the restored TableCacheStatusEnable metadata with the missing lock row and verify that the chosen behavior—restoring the runtime owner or rejecting the unsupported DDL window—allows a fresh-session INSERT to succeed.

Written by the indexing model from the issue text.