[import] IMPORT INTO can leave durable rows without secondary indexes after index-engine terminal failure

## Bug Report

> Evidence status: confirmed.

### 1. Minimal reproduce step (Required)

```sql
Set GLOBAL tidb_enable_dist_task=OFF. Create src(a PK,b) with rows (1,10),(2,20),(3,30) and dst(a PK,b,INDEX ib(b)). Inject an index-engine terminal error immediately after closedDataEngine.Import succeeds and before indexEngine.Close. Run IMPORT INTO dst FROM SELECT a,b FROM src. Then compare dst IGNORE INDEX(ib), dst USE INDEX(ib) WHERE b>=0, and ADMIN CHECK TABLE dst.
```

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

If IMPORT INTO returns an error, it must not leave an unrecoverable physical inconsistency. Either no durable target KVs are visible, or every visible row has its required secondary-index entries and recovery state remains available.

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

The statement returns ERROR 1105. A table scan returns 3 rows, the forced ib scan returns 0 rows, and ADMIN CHECK TABLE returns ERROR 8223. No-fault control is 3/3/green; a fault before data-engine Import is 0/0/green.

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

current master 13282a8bd06b; standalone IMPORT INTO FROM SELECT with local sort

Likely root cause and fix direction

ImportSelectedRows closes and irreversibly imports the data engine before closing/importing the index engine. A later index Close/Import error returns to the user; deferred cleanup cannot roll back imported record KVs and removes local index-engine recovery state.

Start by locating ImportSelectedRows and trace the sequence around closedDataEngine.Import, indexEngine.Close, and index-engine error cleanup for standalone IMPORT INTO FROM SELECT with local sort. Reproduce the SQL case with the injected terminal failure, then verify that an error leaves no visible target KVs or preserves all secondary-index entries and recovery state; ADMIN CHECK TABLE should remain clean.

Written by the indexing model from the issue text.