[Bug]: DELETE FROM ... PARTITION ignores the partition list and deletes every row

### MatrixOne version

`4fdb9e91615f9fc37703039ae28a47849206d1d6` (latest main when reproduced), Linux/amd64 standalone launch deployment.

### What happened?

The parser accepts the single-table MySQL form `DELETE FROM t PARTITION (p0)`, but the delete planner does not consume `tree.Delete.PartitionNames`. The delete source therefore scans the whole logical table and every row is deleted.

This was found while challenging #28309/#28310 with adjacent delete-scope restrictions. #28310 deliberately prevents partition-restricted statements from being classified as unrestricted/truncatable, but it does not implement partition pruning; this issue needs its own planner/storage design.

### Reproduction

```sql
drop database if exists delete_partition_scope;
create database delete_partition_scope;
use delete_partition_scope;

create table p(
id int primary key,
body text
) partition by hash(id) partitions 2;

insert into p values
(1, 'odd token'),
(2, 'even token'),
(3, 'odd three');

delete from p partition(p0);
select id from p order by id;
```

### Actual behavior

The final SELECT returns no rows: rows outside `p0` are also deleted.

### Expected behavior

Only rows in the named partition are eligible for deletion. If partition-qualified DELETE is not supported, planning must reject it explicitly before mutation; it must never silently widen the delete set.

### Root-cause direction

- `pkg/sql/parsers/tree/delete.go` stores `PartitionNames`.
- The MySQL grammar populates it for single-table DELETE.
- The ordinary delete planning paths do not turn the list into a partition-restricted scan/filter.

A systematic fix should make the partition list part of the delete row-selection contract, validate unknown/duplicate partition names, preserve index/FK maintenance for only selected rows, and cover hash/range/list plus empty/multi-partition cases.