[kvlonge]

Why

Custom rules read SQL structure through a Polyglot tree that SQLBuild's analysis no longer uses, so rules and analysis could disagree. The rules tree now comes from the SQLQuack parser chosen per dialect.

Changes

• SqlDocument is native. ast() returns a SqlTreeNode tree (kind, line, column, children, walk()); polyglot_ast() is removed.
• PostgreSQL uses the native PostgreSQL parser. DuckDB, MotherDuck, Snowflake and SQLite use SQLQuack's shared parser. Other dialects raise RuleUsageError (unavailable), as do syntax errors, PostgreSQL's stack-depth refusal, parser gaps and statements kept as unparsed text.
• ctes(), joins(), subqueries() and star_projections() keep their SqlNode output. Fixes against the Polyglot version: positions are each node's own start in the source, joins() reports only explicit joins, and nested WITH CTEs are found. star_projections() skips an aggregate's *, as before.
• The walk is iterative, on a 16 MB-stack worker helper that two analysis workers now share.
• Rules benchmark and cold-compile statistics read the SQLQuack tree. The polyglot-sql-chio dependency stays until local scenario execution moves off it.
• Docs: rule-context page and its skill copy.

Verification

• Corpus of 8,617 models (DuckDB, PostgreSQL, Snowflake, SQLite), old vs new: identical parse failures. CTE, subquery and star counts match except 8 nested-WITH models (Polyglot missed them). Join counts match a JOIN token count except 1 model of comma FROM items, fixed here with a test.
• Rust tree tests; an E2E custom rule over ast() and each method checks positions against the source text.
• make check-ci, fensu, rules e2e/integration, rules benchmark unit tests. The 3,000/5,000-model rules guards time out locally on the 0.197.0 and 0.198.0 wheels too; this branch is not slower.

DuckShop: not applicable; custom-rule API surface, no project shape, data value or lifecycle sequence.