mview: define CDC-compatible DDL metadata contract for materialized view logs

## Bug Report

Please answer these questions before submitting your issue. Thanks!

### 1. Minimal reproduce step (Required)

Related TiCDC issue: https://github.com/pingcap/ticdc/issues/5560

Start a TiDB cluster with MView/MLog support and a TiCDC new architecture changefeed that replicates a schema wildcard to a MySQL sink:

```toml
# TiCDC config
newarch = true
```

Example upstream SQL:

```sql
DROP DATABASE IF EXISTS cdc_mlog_repro;
CREATE DATABASE cdc_mlog_repro;
USE cdc_mlog_repro;

CREATE TABLE t_base (
id BIGINT NOT NULL PRIMARY KEY,
g1 INT NOT NULL,
v1 BIGINT NOT NULL,
v2 DECIMAL(10,2) NOT NULL,
c1 INT NULL,
pad VARCHAR(64) NOT NULL DEFAULT '',
KEY idx_g1 (g1)
);

CREATE MATERIALIZED VIEW LOG ON cdc_mlog_repro.t_base (id, g1, v1, v2, c1, pad)
PURGE NEXT DATE_ADD(NOW(), INTERVAL 1 HOUR);

INSERT INTO cdc_mlog_repro.t_base (id, g1, v1, v2, c1, pad)
VALUES
(1, 1, 10, 1.00, 10, 'a'),
(2, 1, 20, 2.00, 20, 'b');

CREATE MATERIALIZED VIEW mv_agg (g1, cnt, s_v1)
REFRESH FAST
AS
SELECT g1, COUNT(*) AS cnt, SUM(v1) AS s_v1
FROM cdc_mlog_repro.t_base
GROUP BY g1;

DROP MATERIALIZED VIEW cdc_mlog_repro.mv_agg;
DROP MATERIALIZED VIEW LOG ON cdc_mlog_repro.t_base;
```

Observed TiDB DDL history in internal validation on 2026-07-03:

```text
create materialized view log: table_id=128, state=synced
create materialized view: table_id=130, state=synced
drop materialized view: table_id=130, state=synced
drop materialized view log: table_id=128, state=synced
```

The drop MView DDL completed successfully before the MLog drop. The MLog drop was exposed as a drop-table-like DDL for the internal `$mlog$...` table ID.

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

The MView/MLog DDL metadata emitted by TiDB should have a CDC-compatible contract.

For `CREATE MATERIALIZED VIEW LOG` and `DROP MATERIALIZED VIEW LOG`, TiDB and TiCDC should agree on one of these behaviors:

- MLog internal tables are first-class DDL objects for CDC, with enough metadata for create/drop handling; or
- MLog internal tables are intentionally hidden from CDC, and both create and drop paths are consistently filtered/ignored.

In either case, executing `DROP MATERIALIZED VIEW LOG` should not leave TiCDC seeing an unmatched drop-table-like DDL for an internal `$mlog$...` table.

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

TiDB emitted the MLog lifecycle as follows:

- `CREATE MATERIALIZED VIEW LOG` created an internal `$mlog$...` table with table ID `128`.
- `DROP MATERIALIZED VIEW` for the MView table ID `130` completed successfully.
- `DROP MATERIALIZED VIEW LOG` was then surfaced as `drop table` for the internal MLog table ID `128`.

TiCDC new architecture panicked while handling the MLog drop:

```text
panic: table not found
github.com/pingcap/ticdc/logservice/schemastore.getTableName(0x85?, 0x80)
github.com/pingcap/ticdc/logservice/schemastore.buildPersistedDDLEventForDropTable(...)
github.com/pingcap/ticdc/logservice/schemastore.(*persistentStorage).handleDDLJob(...)
```

`0x80` is decimal `128`, matching the internal MLog table ID. The corresponding TiCDC tracking issue is https://github.com/pingcap/ticdc/issues/5560.

This TiDB issue is for tracking the TiDB/MView side of the contract: whether `CREATE/DROP MATERIALIZED VIEW LOG` should expose a dedicated DDL action/metadata to CDC, or whether TiDB should mark internal MLog objects so external CDC consumers can consistently skip them.

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

Exact `SELECT tidb_version()` output was not preserved before the internal validation testbed was recycled. The observed environments used these image tags / commit suffixes:

```console
TiDB:
- v8.5.4-20260513-3feb56e-10422
- also observed with v8.5.4-20260701-190c9d5-enterprise

TiKV:
- v8.5.4-20260316-c69cb9b-10004

PD:
- feature-release-8.5-materialized-view-53721a2

TiCDC:
- v8.5.4-20260608-5445ede
- commit observed from test metadata: 5445ede092e3ef1f6b5ec432f5d74f7e38c9e1c8

TiCDC config:
- newarch = true
```

Start with the reproduction SQL and the TiCDC schemastore stack entries getTableName and buildPersistedDDLEventForDropTable described in the report, then review the related TiCDC issue 5560. Define and validate whether materialized view log create/drop events are exposed with sufficient metadata or consistently filtered; done means the drop no longer produces an unmatched internal-table DDL or panic.

Written by the indexing model from the issue text.