Non-prepared plan cache has a narrower SQL support range than prepared plan cache

## Enhancement

TiDB currently has different SQL support ranges for prepared and non-prepared plan cache. For non-prepared statements, an additional conservative AST allowlist is applied before automatic parameterization. As a result, some SQL structures that can be handled by the prepared plan cache are rejected when the same SQL is sent through the text protocol. Examples include some statements containing:

- `HAVING`
- window functions
- CTEs and set operations
- joins involving multiple tables

The non-prepared form may bypass the plan cache because of the independent AST allowlist.

**Impact**
1. The text protocol can miss plan-cache opportunities for repeatedly executed SQL statements.
2. Support for new SQL constructs may need to be added to multiple independent checkers.

**Expected outcome**
Non-prepared plan cache should not reject a statement solely because its AST shape is missing from a separate structural allowlist.

Start by locating the non-prepared plan-cache AST allowlist and the prepared and non-prepared plan-cache checks. Compare how statements with HAVING, window functions, CTEs, set operations, and multi-table joins are handled, then trace the relevant plan-cache tests. Done means non-prepared statements are not rejected solely by a separate structural allowlist and existing coverage verifies the shared SQL support range.

Written by the indexing model from the issue text.