routing: incorrect rule matching and CREATE VIEW rewriting

What did you do?

Used table routing in TiCDC's new architecture. The following configurations and DDLs expose independent problems:

• Set changefeed case-sensitive = true and route Sales.* while the source table is sales.orders.
• Create a changefeed with an invalid route matcher ([) and no source tables.
• Place a table-only route for sales.orders before an MQ rule for sales.* with topic sales-events and partition ts.
• Use {schema}_{table} with source schema db{table} and table orders.
• Route test.* to dst.{table}_r and create views using SELECT t.* FROM t or WITH c AS (SELECT id FROM t) SELECT id FROM c.

What did you expect to see?

Routing should honor the changefeed configuration, validate matchers regardless of table count, preserve MQ dispatch behavior and literal source names, and preserve view query results.

What did you see instead?

• The dispatcher uses the sink-level case-sensitivity field, producing different routes from API validation and the maintainer.
• Invalid matchers pass validation when the table set is empty.
• Table-only routing rules shadow MQ rules, changing the topic and partition selection.
• Placeholder substitution processes inserted source text again: db{table}_orders becomes dborders_orders.
• Qualified wildcards retain the old table name. CTE references are renamed as physical tables, such as dst.c_r, causing view creation failures or incorrect results when that physical table exists.

Scope and likelihood

These issues require specific configuration combinations, unusual identifiers, or particular view definitions, so they are expected to be uncommon in typical production use. This assessment is based on the trigger conditions, not measured incident rates. When triggered, they can still cause incorrect routing or interrupt replication.