[ddl] Parent-first batch DROP TABLE can leave persistent foreign-key orphans

## Bug Report

### 1. Minimal reproduce step (Required)

**Environment**

current master 231dad5225 and official nightly; MDL ON and foreign_key_checks ON

**Steps**

Create p and FK child c. Run DROP TABLE IF EXISTS p,,c. After p disappears and before c is reached, run RENAME TABLE c TO c_survivor. Both statements return success. Insert another child row while p is absent, recreate p with a different key, and anti-join child to parent.

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

A parent drop must not become durable while a referring child can survive the same admitted batch.

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

The parent is absent, c_survivor retains REFERENCES p(id), two orphan rows persist after p is recreated, and ADMIN CHECK TABLE remains green.

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

current master 231dad5225 and official nightly; MDL ON and foreign_key_checks ON

Likely root cause and fix direction

**Likely root cause**

The batch precheck and every parent job ignore all child names in the complete request, although objects are committed as independent sequential DDL jobs. A mutable future child name is treated as an already-completed effect.

**Fix direction**

Make the batch atomic or exempt only identity-bound children already removed by committed jobs; revalidate latest FK references before publishing the parent drop.

Start by reproducing the DROP TABLE, RENAME TABLE, insert, and parent-recreation sequence with MDL and foreign_key_checks enabled. Trace the batch precheck and parent jobs described in the issue, then verify that the completed behavior prevents a durable parent drop when a child can survive the batch and leaves no persistent foreign-key orphans.

Written by the indexing model from the issue text.