Table schema lost in optimistic transaction

## Bug Report

Please answer these questions before submitting your issue. Thanks!

### 1. Minimal reproduce step (Required)
1. restart the cluster
2. use following python3 script(rename the file before executing) to execute the testcase

[reproduce.txt](https://github.com/user-attachments/files/31544232/reproduce.txt)

[testcase.sql](https://github.com/user-attachments/files/31544310/testcase.sql)

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

Query executed successfully.

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

```sql
[generate] Executing: delete from mysql.opt_rule_blacklist;
[generate] Output: delete from mysql.opt_rule_blacklist;
Query OK, 0 rows affected (0.00 sec)

[generate] Executing: admin reload opt_rule_blacklist;
[generate] Output: admin reload opt_rule_blacklist;
Query OK, 0 rows affected (0.00 sec)

[generate] Executing: create table t1(c0 bool zerofill default false )partition by hash(c0) partitions 60;
[generate] Output: create table t1(c0 bool zerofill default false )partition by hash(c0) partitions 60;
Query OK, 0 rows affected, 1 warning (0.02 sec)

[generate] Executing: delete from mysql.expr_pushdown_blacklist;admin reload expr_pushdown_blacklist;
[generate] Output: delete from mysql.expr_pushdown_blacklist;admin reload expr_pushdown_blacklist;
Query OK, 0 rows affected (0.01 sec)

Query OK, 0 rows affected (0.00 sec)

[generate] Executing: alter table t1 add primary key(c0);
[generate] Output: alter table t1 add primary key(c0);
Query OK, 0 rows affected (0.12 sec)

[generate] Executing: replace into t1 values (false), (false), (false);
[generate] Output: replace into t1 values (false), (false), (false);
Query OK, 3 rows affected (0.00 sec)
Records: 3 Duplicates: 0 Warnings: 0

[generate] Executing: update t1 set c0=0.8443959185783887;
[generate] Output: update t1 set c0=0.8443959185783887;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0

[mirror_init] Executing: use test_repro
[mirror_init] Output: use test_repro
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed

[ORIGINAL] Executing: BEGIN OPTIMISTIC;
[ORIGINAL] Output: BEGIN OPTIMISTIC;
Query OK, 0 rows affected (0.01 sec)

[ORIGINAL] Executing: INSERT INTO t1(c0) VALUES (false), (true);
[ORIGINAL] Output: INSERT INTO t1(c0) VALUES (false), (true);
Query OK, 2 rows affected (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 0

[ORIGINAL] Executing: BEGIN PESSIMISTIC;
[ORIGINAL] Output: BEGIN PESSIMISTIC;
Query OK, 0 rows affected (0.00 sec)

[ORIGINAL] Executing: INSERT DELAYED IGNORE INTO t1 VALUES (true), (false) ON DUPLICATE KEY UPDATE c0=(('w')AND(-105629829));
[ORIGINAL] Output: INSERT DELAYED IGNORE INTO t1 VALUES (true), (false) ON DUPLICATE KEY UPDATE c0=(('w')AND(-105629829));
Query OK, 2 rows affected, 1 warning (0.01 sec)
Records: 2 Duplicates: 1 Warnings: 1

[ORIGINAL] Executing: SET SESSION tidb_read_staleness = -5;
[ORIGINAL] Output: SET SESSION tidb_read_staleness = -5;
Query OK, 0 rows affected (0.00 sec)

[ORIGINAL] Executing: BEGIN OPTIMISTIC;
[ORIGINAL] Output (first 300 chars): BEGIN OPTIMISTIC;
ERROR 9007 (HY000): Write conflict, txnStartTS=468687180854460416, conflictStartTS=468687180882247680, conflictCommitTS=0, key={tableID=116, tableName=unknown, indexID=1, indexValues={1, }}, originalKey=7480000000000000745f698000000000000001040000000000000001, primary=[]byte(nil),...
[ORIGINAL] Executing: SHOW TABLES;
[ORIGINAL] Output: SHOW TABLES;
+----------------------+
| Tables_in_test_repro |
+----------------------+
| t1 |
+----------------------+
1 row in set (0.00 sec)

[ORIGINAL] Executing: SELECT t1.c0 FROM t1 WHERE t1.c0;
[ORIGINAL] Output: SELECT t1.c0 FROM t1 WHERE t1.c0;
ERROR 1146 (42S02): Table 'test_repro.t1' doesn't exist

```

SHOW TABLES showed that t1 exists but SELECT reported not.

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

```sql
mysql> select version();
+-----------------------------------------------------+
| version() |
+-----------------------------------------------------+
| 8.0.11-TiDB-v9.0.0-beta.1.pre-640-g24903d6b24-dirty |
+-----------------------------------------------------+
1 row in set (0.00 sec)

```

Start by running the Python reproduction in reproduce.txt with testcase.sql against the reported TiDB version, focusing on the BEGIN OPTIMISTIC write-conflict sequence. Trace the handling of the conflict before SHOW TABLES and SELECT t1.c0; done means t1 remains queryable after the conflict instead of reporting that the table does not exist.

Written by the indexing model from the issue text.