feat(analysis): type LIKE and ILIKE patterns and resolve null tests

[omer-cengel]

Summary

Text search and null checks are common in everyday read queries, but a LIKE $1 or ILIKE $1 pattern placeholder was rejected, and an IS NULL test was never checked against the schema. A LIKE/ILIKE pattern placeholder on a direct text column now becomes a typed String method parameter. A direct-column IS NULL/IS NOT NULL now resolves its column against the query sources.

Changes

• <column> LIKE $N and <column> ILIKE $N on a direct, optionally qualified VARCHAR or TEXT column produce one parameter typed from that column. They keep textual binding order and follow the existing repeated-index and contiguity rules, in SELECT, UPDATE, and DELETE WHERE clauses.
• <column> IS NULL and IS NOT NULL resolve their direct column, so an unknown, ambiguous, or badly qualified column is rejected. They bind no parameter.
• A pattern placeholder is rejected with a focused message in these cases: negated (NOT LIKE, NOT ILIKE), another keyword such as SIMILAR TO, an ESCAPE clause, a BINARY modifier, a non-text tested column, or a placeholder as the tested value. A named :name placeholder in either operand keeps the existing named-parameter message.
• Analyzer tests cover these cases, and a PostgreSQL integration test generates, compiles, and runs LIKE, case-insensitive ILIKE, IS NULL, and IS NOT NULL reads.
• The query documentation describes the new predicate forms, caller-supplied %/_ wildcards, the rejections, and the remaining unanalyzed forms.

Scope and non-goals

• A literal LIKE pattern still reaches the database unanalyzed.
• A placeholder inside a computed pattern such as '%' || $1 || '%', and a placeholder null test such as $1 IS NULL, stay rejected as unsupported placeholder locations.
• PostgreSQL ISNULL/NOTNULL postfix spellings and NOT (...) predicates are not analyzed.
• The query model, the Java generator, and the runtime are unchanged.