fix: add DuckDB dialect UDFs so flush partition filters run over SPI

[qsliu2017]

CALL ducklake.set_partition(tbl, 'month(col)') (or any non-identity transform: year/month/day/hour/bucket) is accepted, but every subsequent ducklake.flush_inlined_data() fails with IO Error: SPI execution failed: function month(timestamp with time zone) does not exist (or murmur3_32(...) for bucket partitions). The maintenance worker keeps retrying the flush and leaves orphaned parquet files behind on each attempt. Root cause: DuckLake embeds the partition expression in DuckDB dialect in the flush's per-file deleted-rows bookkeeping query, and pg_ducklake ships that query to PostgreSQL over SPI, whose parser has no such functions.

Per maintainer decision, the bookkeeping query stays on the PG/SPI path and the dialect gap is filled instead: the new extension objects are ducklake.year/month/day/hour (date, timestamp, timestamptz, plus hour(time) -- the only transform DuckDB accepts on TIME) and ducklake.murmur3_32 overloads for boolean, all integer widths, real, double precision, text, bytea, date, time, timestamp, timestamptz, numeric, and uuid. The murmur3 implementations reuse the vendored DuckLake murmur3 header, so they are bit-exact with the writer by construction; the SPI executor forces search_path=ducklake for metadata queries (via the existing GUC nest-level pattern) so the unqualified names resolve deterministically and cannot collide with e.g. orafce's month() in public.

Verifying against writer-side ground truth surfaced two additional silent-corruption bugs, both fixed here. First, the inlined table stores text columns as BYTEA, so the upstream filter's CAST(col AS VARCHAR) compared PG's hex form ('\x6170706c65') instead of the string -- every text bucket mis-hashed and every text identity comparison missed, writing delete tombstones onto the wrong rows. Second, without an exact numeric overload PostgreSQL resolves murmur3_32(numeric) to the double precision one (the preferred numeric type) and silently mis-buckets. Fixing the first required a small new vendored seam (ducklake-010 patch): a metadata-manager virtual through which the backend renders each partition column per its inlined storage type (convert_from() for text-as-BYTEA, raw column for bytea, ::text for decimals wider than 18 digits, PG-parseable type names otherwise).

One documented limitation: timestamptz calendar transforms depend on the session TimeZone in both engines, and DuckDB syncs its TimeZone from PostgreSQL only once, at instance creation -- a mid-session SET timezone can make writer and bookkeeping disagree near month/year boundaries. Accepted as inherent to evaluating in two engines.

Tests: nine flush-with-delete scenarios (month on timestamptz incl. NULL partitions, bucket on int/text/numeric(18,3)/numeric(30,10)/uuid/bytea, identity on text, hour on time) plus a PG-vs-DuckDB equivalence matrix pinned to the Iceberg spec reference vectors that fails loudly on any dialect drift. Full regression suite: 52/52 on main.

This PR now targets main because it adds SQL interface (new extension objects, shipped in the in-development 1.1.0 update script). Orphaned parquet files left by past failed flushes are recoverable with ducklake.cleanup_orphaned_files().

Fixes #223

🤖 Generated with Claude Code