respect `case-sensitive` in schema store

What did you do?

The schema store currently uses different sources for schema/table names depending on the DDL type. Most paths use catalog metadata, while some paths use names from the original SQL or job.TableName. These values may differ only in letter case.

With case-sensitive table filters enabled, the same catalog object can therefore be treated as a different table.

The affected paths include:

• CREATE TABLE ... LIKE: the referenced table name is parsed from SQL when checking the filter and barrier dependency.
• RENAME TABLE and ALTER TABLE ... RENAME TO: the old table identity is reconstructed from SQL and used for filtering and barrier/name-change handling.
• RENAME TABLES: the same issue applies to each old table name.
• CREATE VIEW and DROP VIEW: the table name is taken from job.TableName, which may be normalized to lower case instead of preserving the catalog name.
• TableNameStore: rename events use exact string keys, so a case mismatch may leave stale table-name entries.

What did you expect to see?

Schema store should resolve DDL objects to their catalog identities before applying table filters or updating internal name state. Original SQL casing should only be preserved where it is required for reconstructing the downstream query.

Please add focused tests covering mixed-case schema/table names with both case-sensitive and case-insensitive filters.

What did you see instead?

As described above.

Versions of the cluster

Upstream TiDB cluster version (execute SELECT tidb_version(); in a MySQL client):

(paste TiDB cluster version here)

Upstream TiKV version (execute tikv-server --version):

(paste TiKV version here)

TiCDC version (execute cdc version):

(paste TiCDC version here)

Start by tracing the schema store paths for CREATE TABLE ... LIKE, RENAME TABLE(S), ALTER TABLE ... RENAME TO, CREATE/DROP VIEW, and TableNameStore rename events. Add focused tests using mixed-case schema and table names with both case-sensitive and case-insensitive filters. Done means DDL objects resolve to catalog identities for filtering and internal name state, while required downstream query reconstruction preserves original SQL casing.