Inconsistent result while executing transaction on partitioned table

## Bug Report

Please answer these questions before submitting your issue. Thanks!

### 1. Minimal reproduce step (Required)

```sql
create table t1(c0 smallint unsigned zerofill , c1 decimal check ((binary (((null)<=(field(((701046147)^(false)), c1)))))) default 1598031266 , c2 float unsigned zerofill default 0.3771185360659034 ) partition by hash(c0) partitions 15;
CREATE TABLE t1_oracle LIKE t1;
alter table t1_oracle remove partitioning;
INSERT INTO t1_oracle SELECT * FROM t1;

session1: SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
session1: START TRANSACTION WITH CONSISTENT SNAPSHOT;
session1: INSERT IGNORE INTO t1(c1, c0) VALUES (536836960, 701046147), (9223372036854775807, 602107015) ON DUPLICATE KEY UPDATE c2=701046147;
session2: INSERT IGNORE INTO t1 VALUES (213868578, 1237030990, 0.6990271184381073) ON DUPLICATE KEY UPDATE c1='-2120232476';
session1: SELECT DISTINCT t1.c0, t1.c1, t1.c2 FROM t1 WHERE ((((t1.c0)!=(NULL)))AND(((t1.c0)>('{,5l핂0|b^')))) UNION SELECT t1.c2, t1.c0, t1.c0 FROM t1 WHERE t1.c1;

then executing these transactions on t1_oracle:
session1: SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
session1: START TRANSACTION WITH CONSISTENT SNAPSHOT;
session1: INSERT IGNORE INTO t1_oracle(c1, c0) VALUES (536836960, 701046147), (9223372036854775807, 602107015) ON DUPLICATE KEY UPDATE c2=701046147;
session2: INSERT IGNORE INTO t1_oracle VALUES (213868578, 1237030990, 0.6990271184381073) ON DUPLICATE KEY UPDATE c1='-2120232476';
session1: SELECT DISTINCT t1_oracle.c0, t1_oracle.c1, t1_oracle.c2 FROM t1_oracle WHERE ((((t1_oracle.c0)!=(NULL)))AND(((t1_oracle.c0)>('{,5l핂0|b^')))) UNION SELECT t1_oracle.c2, t1_oracle.c0, t1_oracle.c0 FROM t1_oracle WHERE t1_oracle.c1;

```

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

SELECT statements return same result.

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

```sql
first query:
mysql> SELECT DISTINCT t1.c0, t1.c1, t1.c2 FROM t1 WHERE ((((t1.c0)!=(NULL)))AND(((t1.c0)>('{,5l핂0|b^')))) UNION SELECT t1.c2, t1.c0, t1.c0 FROM t1 WHERE t1.c1;
+------------+-------+-------+
| c0 | c1 | c2 |
+------------+-------+-------+
| 0.6990271 | 65535 | 65535 |
| 0.37711853 | 65535 | 65535 |
+------------+-------+-------+
2 rows in set, 2 warnings (0.00 sec)

second query:
mysql> SELECT DISTINCT t1_oracle.c0, t1_oracle.c1, t1_oracle.c2 FROM t1_oracle WHERE ((((t1_oracle.c0)!=(NULL)))AND(((t1_oracle.c0)>('{,5l핂0|b^')))) UNION SELECT t1_oracle.c2, t1_oracle.c0, t1_oracle.c0 FROM t1_oracle WHERE t1_oracle.c1;
+------------+------------+-----------+
| c0 | c1 | c2 |
+------------+------------+-----------+
| 65535 | 1237030990 | 0.6990271 |
| 0.37711853 | 65535 | 65535 |
| 0.6990271 | 65535 | 65535 |
+------------+------------+-----------+
3 rows in set, 2 warnings (0.00 sec)

```

### 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 supplied SQL transaction sequence on the partitioned table and its non-partitioned LIKE copy using the reported TiDB version. Compare both SELECT results and warnings, then trace the transaction and partitioned-table execution paths to identify where they diverge. Done means both tables return the same result for this reproduction.

Written by the indexing model from the issue text.