REORGANIZE/REMOVE PARTITIONING silently drops a row from a clustered partitioned table after EXCHANGE PARTITION ... WITHOUT VALIDATION duplicates a primary key

## Bug Report

Please answer these questions before submitting your issue. Thanks!

### 1. Minimal reproduce step (Required)

```sql
SET GLOBAL tidb_enable_exchange_partition = 1;

CREATE TABLE t(
a INT, b INT, c VARCHAR(20),
PRIMARY KEY(a,b) -- clustered
)
PARTITION BY RANGE (b) (
PARTITION p0 VALUES LESS THAN (10),
PARTITION p1 VALUES LESS THAN (20),
PARTITION pmax VALUES LESS THAN (MAXVALUE)
);
INSERT INTO t VALUES (1,1,'p0-row');

CREATE TABLE tx LIKE t;
ALTER TABLE tx REMOVE PARTITIONING;
INSERT INTO tx VALUES (1,1,'p1-row');

ALTER TABLE t EXCHANGE PARTITION p1 WITH TABLE tx WITHOUT VALIDATION;

SELECT COUNT(*) FROM t; -- 2
SELECT * FROM t; -- (1,1,'p0-row'), (1,1,'p1-row')

ALTER TABLE t REORGANIZE PARTITION p0,p1
INTO (PARTITION p01 VALUES LESS THAN (20));

SELECT COUNT(*) FROM t; -- 1
SELECT * FROM t; -- only one row survives
ADMIN CHECK TABLE t; -- passes
```

`ALTER TABLE t REMOVE PARTITIONING`, `ALTER TABLE t PARTITION BY HASH(a) PARTITIONS 4`,
`PARTITION BY KEY`, and `COALESCE PARTITION` after the same exchange setup also
drop one duplicate row.

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

The partition DDL should preserve the visible row multiset or fail with a
duplicate-key error. It must not silently overwrite/drop one row.

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

The DDL succeeds with a normal result, `COUNT(*)` drops from 2 to 1, and
`ADMIN CHECK TABLE` reports no error. Which row survives may depend on scan
order; distinct non-key data can be lost.

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

```
Release Version: v8.4.0-this-is-a-placeholder
Edition: Community
Git Commit Hash: None
Git Branch: None
UTC Build Time: None
```

Built from source commit `a514a92784c9654502686e6ee6efc9e0aeda8afa` (pingcap/tidb master, 2026-09-07).

Related: #69648 is the nonclustered `_tidb_rowid` sibling of this issue.