[prql-bot]

The book's date.trunc section said only "Truncates a date or timestamp to a
given unit", which leaves two things a reader hits in practice undocumented:

• The emitted SQL is not one shape. MSSQL emits DATETRUNC(day, col) and
  BigQuery emits DATE_TRUNC(col, DAY) — different function name, different
  argument order, unquoted unit — while every other dialect emits
  DATE_TRUNC('day', col). That matters when reading the compiled SQL or
  checking which units a target accepts.
• SQLite is unsupported. date.trunc there raises
  operator std.date.trunc is not supported for dialect sqlite (date.trunc generates invalid SQL for SQLite target #5730, fixed in
  fix: date.trunc returns error for SQLite instead of invalid SQL #5733 so it errors rather than emitting invalid SQL), but the page never said
  so. The sibling date.diff section already carries the equivalent note, added
  in docs: document date.diff in the date functions page #6264.

This adds a per-dialect output table and the SQLite note, mirroring how diff
and now are documented on the same page, plus the cross-reference that the
unit is a string here and a bare keyword for date.diff.

Every row of the new table is now covered by a test, so the page can't drift
from the compiler: date_trunc_operator gains generic and clickhouse cases,
and date_trunc_snowflake covers the one row that doesn't fit that test's
shared template (Snowflake quotes identifiers). SQLite was already covered by
date_trunc_unsupported_dialects.

Verification

Each table row was read off prqlc compile at 66d8267, not inferred from
std.sql.prql:

generic     SELECT DATE_TRUNC('day', event_time) FROM events
duckdb      SELECT DATE_TRUNC('day', event_time) FROM events
postgres    SELECT DATE_TRUNC('day', event_time) FROM events
mysql       SELECT DATE_TRUNC('day', event_time) FROM events
clickhouse  SELECT DATE_TRUNC('day', event_time) FROM events
snowflake   SELECT DATE_TRUNC('day', "event_time") FROM "events"
mssql       SELECT DATETRUNC(day, event_time) FROM events
bigquery    SELECT DATE_TRUNC(event_time, DAY) FROM events
sqlite      Error: operator std.date.trunc is not supported for dialect sqlite

The two dialect forms come from process_date_trunc in
prqlc/prqlc/src/sql/gen_expr.rs:216; everything else routes through the
generic trunc in prqlc/prqlc/src/sql/std.sql.prql:154, which SQLite
overrides with null at line 447.

task prqlc:pull-request passes except queries::results::read_csv, which
fails in this sandbox because DuckDB can't reach extensions.duckdb.org to
fetch its json extension — unrelated to this change, and it should pass on CI.
cargo insta test -p mdbook-prql (the book's own tests) passes, and prettier
reports the page clean.

No CHANGELOG.md entry: compiler behavior is unchanged, so there's nothing
user-facing to record beyond the docs themselves.

[prql-bot]

The new sentence on how the unit is written stops one step short of what the compiler enforces: date.trunc requires a string literal, not any text value. Piping a unit column through it — which "written as a string" reads as permitted — fails with `std.date.trunc` only supports a string literal as unit (pinned by error_messages::date_trunc_with_column_unit), and the page gives no hint why. That's the same class of gap this PR set out to close, so it belongs in the same sentence.

Smaller: the guardrail comment on date_trunc_operator says each row of the table needs a case there, but the Snowflake row's case is date_trunc_snowflake. A contributor adding a dialect that quotes identifiers — Oracle emits the Snowflake form — follows the comment into a template that can't hold it.