Internal Transaction Error: PessimisticLockNotFound with LockMissingAmendFail during COMMIT in RC isolation.

## Bug Report

Please answer these questions before submitting your issue. Thanks!

### 1. Minimal reproduce step (Required)
DROP TABLE IF EXISTS mtest;
CREATE TABLE mtest(c0 CHAR(12), c1 INT DEFAULT NULL, c2 TEXT, INDEX i0 (c0(5), c1));

INSERT INTO mtest(c0, c1, c2) VALUES ('{JQ', NULL, 'f');
INSERT INTO mtest(c0, c1, c2) VALUES ('', 97, NULL);
INSERT INTO mtest(c0, c1, c2) VALUES ('e', 72, 'w');
INSERT INTO mtest(c0, c1, c2) VALUES ('ANT]%U[Q隷', 1, '');
INSERT INTO mtest(c1) VALUES (38);
INSERT INTO mtest(c2) VALUES ('e쌤Fj|Xc');
INSERT INTO mtest(c1, c2) VALUES (9, 'Ewt讘F#o/');
INSERT INTO mtest(c0, c1, c2) VALUES ('9]+*', 98, 'b4>}Cb?C~()');
View{
1:[{JQ, null, f]
2:[, 97, null]
3:[e, 72, w]
4:[ANT]%U[Q隷, 1, ]
5:[null, 38, null]
6:[null, null, e쌤Fj|Xc]
7:[null, 9, Ewt讘F#o/]
8:[9]+*, 98, b4>}Cb?C~()]
}

-- ============================================================
-- (Tx1: Session A, Tx2: Session B)
-- ============================================================

-- Step 1 (Session B - Tx2):
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN;
-- Tx2 开始更新，锁定 c1=9 和 c1=97 的行，并将它们的 c0 改为 ""
UPDATE mtest SET c0 = "", c1 = 13, c2 = "W~MGw." WHERE c1 IN (9, 97);

-- Step 2 (Session A - Tx1):
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN;
UPDATE mtest SET c0 = "L?]OgLl", c1 = 77 WHERE c0 = '';

-- Step 3 (Session B - Tx2):
SELECT c0, c1, c2 FROM mtest WHERE TRUE LIMIT 3;
COMMIT;

-- Step 4 (Session A - Tx1):
SELECT c1 FROM mtest WHERE c1 BETWEEN LEAST(72, 97) AND GREATEST(72, 97); ---- [77, 77, 77, 77]
COMMIT;

-- Step 5
SELECT * FROM mtest;

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

①Successful Transaction Commit: In READ COMMITTED isolation, Tx1 should be able to commit successfully after the lock conflict is resolved. The database should handle the "Pessimistic Lock Amend" process internally without throwing low-level KV errors.
②Deterministic Data Consistency:
After Tx2 commits, Tx1's UPDATE statement (which was previously blocked) should re-evaluate the rows. It should correctly see all rows where c0 = "" (including the ones newly updated by Tx2) and update them.
In this specific case, 4 rows were expected to be updated to c1 = 77.
③Transaction Atomicity: If a COMMIT fails with an error like tikv aborts txn, the transaction should be fully rolled back, and the data should remain in the state it was after Tx2's commit. An internal engine error during commit should not leave the database in an uncertain state.
④Standard SQL Error Handling: If there is a write conflict or a constraint violation, TiDB should return a standard SQL error code (e.g., Error 1213: ⑤Deadlock or Error 1062: Duplicate Entry), instead of a raw internal TiKV error message like PessimisticLockNotFound.

### 3. What did you see instead (Required)
mysql> commit;
ERROR 1105 (HY000): tikv aborts txn: Error(Txn(Error(Mvcc(Error(PessimisticLockNotFound { start_ts: TimeStamp(465108671660294145), key: [116, 128, 0, 0, 0, 0, 7, 149, 202, 95, 114, 128, 0, 0, 0, 0, 0, 0, 2], reason: LockMissingAmendFail })))))
mysql> select * from mtest;
+------------+------+-------------+
| c0 | c1 | c2 |
+------------+------+-------------+
| {JQ | NULL | f |
| L?]OgLl | 77 | W~MGw. |
| L?]OgLl | 77 | W~MGw. |
| ANT]%U[Q隷 | 1 | |
| L?]OgLl | 77 | W~MGw. |
| NULL | NULL | e?Fj|Xc |
| L?]OgLl | 77 | W~MGw. |
| 9]+* | 98 | b4>}Cb?C~() |
+------------+------+-------------+
### 4. What is your TiDB version? (Required)
Release Version: v7.5.1
Edition: Community
Git Commit Hash: 7d16cc79e81bbf573124df3fd9351c26963f3e70
Git Branch: heads/refs/tags/v7.5.1
UTC Build Time: 2024-02-27 14:28:32
GoVersion: go1.21.6
Race Enabled: false
Check Table Before Drop: false
Store: tikv