The update of TiFlash replica status for all tables in the cluster may be blocked by a DML statement on one of the tables.

## Bug Report

Please answer these questions before submitting your issue. Thanks!

### 1. Minimal reproduce step (Required)

```
CREATE TABLE `test`.`employees1` (
`id` int NOT NULL,
`fname` varchar(30) DEFAULT NULL,
`lname` varchar(30) DEFAULT NULL,
`hired` date NOT NULL DEFAULT '1970-01-01',
`separated` date DEFAULT '9999-12-31',
`job_code` int DEFAULT NULL,
`store_id` int NOT NULL
)
PARTITION BY RANGE (`store_id`)
(PARTITION `p0` VALUES LESS THAN (6),
PARTITION `p1` VALUES LESS THAN (11),
PARTITION `p2` VALUES LESS THAN (16),
PARTITION `p3` VALUES LESS THAN (21),
PARTITION `p4` VALUES LESS THAN (26));

CREATE TABLE `test`.`employees2` (
`id` int NOT NULL,
`fname` varchar(30) DEFAULT NULL,
`lname` varchar(30) DEFAULT NULL,
`hired` date NOT NULL DEFAULT '1970-01-01',
`separated` date DEFAULT '9999-12-31',
`job_code` int DEFAULT NULL,
`store_id` int NOT NULL
)
PARTITION BY RANGE (`store_id`)
(PARTITION `p0` VALUES LESS THAN (6),
PARTITION `p1` VALUES LESS THAN (11),
PARTITION `p2` VALUES LESS THAN (16),
PARTITION `p3` VALUES LESS THAN (21),
PARTITION `p4` VALUES LESS THAN (26));

insert into test.employees1(id, store_id) values (1, 5),(2, 10),(3, 15),(4, 20),(5, 25);
insert into test.employees2(id, store_id) values (1, 5),(2, 10),(3, 15),(4, 20),(5, 25);
```

| session 1 | session 2 | session 3 |
| --- | --- | --- |
| begin; | | |
| select * from test.employees2 for update; | | |
| | alter table test.employees1 set tiflash replica 1; | |
| | alter table test.employees2 set tiflash replica 1; | |
| | | select * from information_schema.tiflash_replica; |
| | | admin show ddl jobs; |
| commit | | |

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

Before session 1 `commit` (or rollback) is called, we should see the "available" field of `test.employees1` should become `1` in session 3 `select * from information_schema.tiflash_replica;` return result.
Session 1 hold a MDL lock on `employees2`, so session 1 should only block the DDL of `employees2` being executed. But **NOT** block the DDL of `employees1` from being executed.

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

Before session 1 `commit` is called, both the "available" field of table `employees1` and `employees2` will not become "1".
Only after session 1 release the MDL lock on `employees1`, both "employees1" and "employees2"'s "available" field will turn to "1"

In session 3, we can observe the query result as follow. Both `employees1` and `employees2` "available" field is 0.
```
> select * from information_schema.tiflash_replica;
+--------------+----------------------+----------+---------------+-----------------+-----------+----------+
| TABLE_SCHEMA | TABLE_NAME | TABLE_ID | REPLICA_COUNT | LOCATION_LABELS | AVAILABLE | PROGRESS |
+--------------+----------------------+----------+---------------+-----------------+-----------+----------+
| test | employees2 | 1388 | 1 | | 0 | 1.0 |
| test | employees1 | 1374 | 1 | | 0 | 1.0 |
+--------------+----------------------+----------+---------------+-----------------+-----------+----------
> admin show ddl jobs;
+--------+-----------+------------+-------------------------------+--------------+-----------+----------+-----------+----------------------------+----------------------------+----------------------------+----------+----------+
| JOB_ID | DB_NAME | TABLE_NAME | JOB_TYPE | SCHEMA_STATE | SCHEMA_ID | TABLE_ID | ROW_COUNT | CREATE_TIME | START_TIME | END_TIME | STATE | COMMENTS |
+--------+-----------+------------+-------------------------------+--------------+-----------+----------+-----------+----------------------------+----------------------------+----------------------------+----------+----------+
| 1429 | test | employees2 | set tiflash replica | public | 234 | 1388 | 0 | 2025-10-29 16:11:05.970000 | 2025-10-29 16:11:05.970000 | | done | |
| 1430 | test | employees2 | update tiflash replica status | none | 234 | 1388 | 0 | 2025-10-29 16:11:07.671000 | | | queueing | |
| 1428 | test | employees1 | set tiflash replica | public | 234 | 1374 | 0 | 2025-10-29 16:11:05.921000 | 2025-10-29 16:11:05.921000 | 2025-10-29 16:11:05.970000 | synced | |
```

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

v8.5.3