docs: fix %-d example in date specifier table

[prql-bot]

The %-d row in the date-specifier table shows its example as ` 8` — space-padded — but %-d maps to Item::Numeric(Numeric::Day, Pad::None) in prqlc/prqlc/src/sql/dialect.rs, i.e. no padding at all. Space-padding is what %k (and chrono's %_d) does, and the table already documents %k separately as "space-padded". The neighbouring %-m row correctly shows 7 with no leading space.

Docs-only, so there's no test to add. Found during the nightly survey of web/book/src/reference/stdlib/date.md.

[prql-bot]

Verified the change by compiling against the Postgres dialect: date.to_text "%-d" emits TO_CHAR(d, 'FMDD'), and the FM prefix suppresses padding entirely — so 8 is the right example and the previous 8 was wrong.

One adjacent thing the same table gets wrong, outside this diff and left for a separate decision: the %k row (Same as %H but space-padded. Same as %_H.) is listed under "specifiers currently supported", but prqlc rejects it. chrono parses %k as Item::Numeric(Numeric::Hour, Pad::Space), and no dialect's translate_chrono_item in prqlc/prqlc/src/sql/dialect.rs has a Pad::Space arm — every one falls through to the unsupported-specifier error. Confirmed by running it: select { a = (d | date.to_text "%k") } fails with PRQL doesn't support this format specifier on both sql.postgres and sql.mysql. Whether the fix is to drop the row or to add space-padding support to the dialect handlers needs a maintainer call, so it's not folded in here.

Sweep of every specifier in the table against `sql.postgres`

%k is the only failing row; the other 27 all compile:

%Y   TO_CHAR(d, 'YYYY')                          %H   TO_CHAR(d, 'HH24')
%y   TO_CHAR(d, 'YY')                            %k   ERROR — unsupported
%m   TO_CHAR(d, 'MM')                            %I   TO_CHAR(d, 'HH12')
%-m  TO_CHAR(d, 'FMMM')                          %p   TO_CHAR(d, 'AM')
%b   TO_CHAR(d, 'Mon')                           %M   TO_CHAR(d, 'MI')
%B   TO_CHAR(d, 'FMMonth')                       %S   TO_CHAR(d, 'SS')
%d   TO_CHAR(d, 'DD')                            %f   TO_CHAR(d, 'US')
%-d  TO_CHAR(d, 'FMDD')                          %R   TO_CHAR(d, 'HH24:MI')
%a   TO_CHAR(d, 'Dy')                            %T   TO_CHAR(d, 'HH24:MI:SS')
%A   TO_CHAR(d, 'FMDay')                         %X   TO_CHAR(d, 'HH24:MI:SS')
%D   TO_CHAR(d, 'MM/DD/YY')                      %r   TO_CHAR(d, 'HH12:MI:SS AM')
%x   TO_CHAR(d, 'MM/DD/YY')                      %+   TO_CHAR(d, 'YYYY-MM-DD"T"HH24:MI:SS.USZ')
%F   TO_CHAR(d, 'YYYY-MM-DD')                    %t %n %%  literals

[prql-bot]

Reproduced the %k finding and filed it as #6139 so it isn't lost when this merges — date.to_text "%k" errors with PRQL doesn't support this format specifier on both sql.postgres and sql.mysql, because no dialect's translate_chrono_item has a Pad::Space arm. The issue lays out both resolutions (drop the row vs. implement space-padding, which needs LPAD rather than a format string on Postgres) plus a related gap: %-H works but isn't in the table, even though %-m and %-d are.

Keeping this PR to the one-line %-d correction.