The docs explicitly mark a set of query-builder APIs as dialect-specific, but the code does not consistently gate them. Treating the docs as the source of truth, unsupported dialects should error (or explicitly no-op) instead of generating potentially invalid SQL.

Affected APIs (per docs, not currently gated:

• .with(...) docs: PostgreSQL, Oracle, SQLite3, MSSQL
• .withRecursive(...) docs: PostgreSQL, Oracle, SQLite3, MSSQL
• .forUpdate() docs: PostgreSQL, MySQL (not supported on Redshift)
• .forShare() docs: PostgreSQL (MySQL uses LOCK IN SHARE MODE)
• .hintComment(...) docs: MySQL, Oracle (ignored elsewhere)
• .crossJoin(...) with join conditions docs: MySQL, SQLite3

When a method is not supported by the current dialect (per docs), the builder/compiler should fail fast with a clear error, or explicitly no-op with a warning if that is the intended behaviour.

We should:

1. Add a per-dialect capability map based on the documentation.
2. Enforce gating for the APIs above (throw or warn/no-op as appropriate).
3. Add tests that assert gating behaviour per dialect.