DXF replan may fail when the owner changed

## Bug Report

Please answer these questions before submitting your issue. Thanks!

### 1. Minimal reproduce step (Required)

1. Start two TiDB/DXF nodes with an explicitly small transaction size limit, for example `txn-total-size-limit=131072`.
2. Run a distributed global-sort `IMPORT INTO` from a very large number of small files (for example 20,000 files / 2 million rows), so planning one step uses the batch-insert subtask path.
3. Kill or transfer the owner after only a prefix of the planned subtask rows has been committed (for example, 51 of 91 rows).
4. Let the new owner re-plan the same logical step. Ensure the input comes from map iteration or another source whose order is not stable, so the new plan has the same length but a different subtask/range order.
5. Wait for the task to finish or fail checksum and compare imported primary keys with the source.

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

Step recovery must identify subtasks by stable content/range identity, or atomically replace the incomplete plan. A retry must cover every source range exactly once regardless of planner order.

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

The recovery logic counts existing subtask rows and inserts only `newSubtasks[existingCount:]`. It does not compare subtask metadata or range identity. If the re-plan produces order B after a prefix of order A was persisted, TiDB accepts `A[:n] + B[n:]` as the plan. The resulting set can omit some ranges and duplicate others.

In the reproduction, 5,655 source ranges were missing and 5,074 were duplicated; only 1,434,500 of 2,000,000 distinct rows were present before the checksum finally made the import fail. With checksum skipped/optional or for task types without an equivalent end verifier, the same framework invariant can turn into silent data loss/duplication.

The trigger depends on a non-default configuration because TiDB otherwise raises the task transaction limit to a very large value. Explicitly configuring a smaller `txn-total-size-limit` reopens the batch path.

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

Reproduced on a master build at commit `1dcb34947971e6265e5a2c3610146e0c44978866`. The same count-prefix logic was still present on upstream/master commit `e26d86f9fb58c1829e75ac7f8bf6caa91bd4693e`.

Start with the TiDB/DXF replan recovery logic described in the report, focusing on how persisted subtask rows are matched after owner transfer and how newSubtasks is sliced by existingCount. Reproduce with two DXF nodes, a small txn-total-size-limit, and a distributed global-sort IMPORT INTO, then verify that every source range is imported exactly once and checksum succeeds after replanning.

Written by the indexing model from the issue text.