resolve lock timeout when executing the transaction

## Bug Report

Please answer these questions before submitting your issue. Thanks!

### 1. Minimal reproduce step (Required)
[S0] means executing in session 1, [S1] means executing in session 2
```sql
SET @@sql_mode='';
[S0] create table t0(c0 decimal unsigned not null , primary key(c0));
[S0] replace into t0(c0) values (-1620598909);
[S0] START TRANSACTION WITH CONSISTENT SNAPSHOT;
[S0] INSERT IGNORE INTO t0(c0) VALUES (-354223166) ON DUPLICATE KEY UPDATE c0=(CASE t0.c0 WHEN t0.c0 THEN t0.c0 WHEN t0.c0 THEN t0.c0 ELSE false END );
[S1] BEGIN OPTIMISTIC;
[S1] UPDATE t0 SET c0 = c0 + 22 WHERE ((t0.c0) IS NOT NULL);
[S1] COMMIT;
```

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

### 3. What did you see instead (Required)
```sql
mysql> COMMIT;
ERROR 9004 (HY000): Resolve lock timeout
```

### 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 two-session SQL reproduction against the reported TiDB version and trace the transaction and lock-resolution path reached by COMMIT. The fix is done when the same sequence completes without ERROR 9004 while preserving the transaction behavior shown in the report.

Written by the indexing model from the issue text.