reduce and observe modify-column pre-check SELECT

## Enhancement

`ALTER TABLE ... MODIFY COLUMN` on the `ModifyTypeIndexReorg` path runs a synchronous pre-check SELECT in `StateDeleteOnly`:

SELECT col FROM t WHERE LENGTH(col) > N OR col IS NULL LIMIT 1

Observed on nextgen with `char(60) -> varchar(70)` on a table with a secondary index: the job stalls in `delete only` for a long time while this SELECT runs. The SELECT has no timeout, pins the cluster GC safepoint for its whole duration, blocks subsequent DDL on the same table, is invisible to `SHOW PROCESSLIST`, reports no progress, only responds to `ADMIN CANCEL DDL JOB` at the 2-second poll boundary, and is filtered out of `statements_summary` by default (internal SQL), so TiDB Dashboard does not catch it either.

### Plan

**Step 1: Skip checks that are statically provable as unnecessary.**

On the `ModifyTypeIndexReorg` path (only reachable via `isCharChange` today), char/varchar flen widening cannot produce a violating row, so the pre-check SQL is skipped for that case.

**Step 2: Replace the remaining necessary checks with a cop-based, observable implementation.**

Drop `ExecRestrictedSQL` in favor of a coprocessor-driven scan: split by region with a fresh startTS per batch (so GC is no longer pinned for the whole scan), push the filter to TiKV, check `stepCtx` at each chunk boundary for fast cancel, and report progress via the existing backfill progress surface.

### Tracking

- [ ] Step 1: widening cases (#67994).
- [ ] Step 2: cop-based pre-check replacement.