Add DuckLake table format support (pg_lake_ducklake)

[sfc-gh-mslot]

This PR adds a new pg_lake_ducklake extension implementing the DuckLake v1 spec with the catalog stored entirely in PostgreSQL. DuckLake tables are foreign tables on a dedicated server backed by the same FDW machinery as pg_lake_table: PostgreSQL owns transaction boundaries and DDL, DuckDB (inside pgduck_server) does the columnar execution, and the catalog itself is plain PostgreSQL tables. The catalog is exposed in two layers, lake_ducklake.* (internal metadata tables) and public.ducklake_* (the spec views DuckDB expects, with INSTEAD-OF triggers routing writes back). Writes participate in the surrounding PG transaction, snapshots are allocated lazily and committed atomically, and DDL flows both ways: PG-side CREATE/ALTER/DROP update the catalog, and DuckDB-side DDL replays back into PostgreSQL via the view triggers.

Concurrent PG-side writers serialise behind a transaction-scoped advisory lock around snapshot allocation. That lock doesn't cover external DuckDB writers, but conflicts between PG and DuckDB writes are still resolved by DuckLake's primary-key-based optimistic concurrency control on the snapshot id, so a losing writer retries.

From PostgreSQL, a DuckLake table is just USING ducklake:

-- set a default storage prefix once; tables land at <prefix>/<schema>/<table>/
set pg_lake_ducklake.default_location_prefix to 's3://mybucket/lake';

-- create a DuckLake table and write to it like any other table
create table measurements (
  station_name text not null,
  measurement  double precision not null
) using ducklake;

insert into measurements values ('Istanbul', 18.5), ('Athens', 21.7);

-- reads, UPDATE/DELETE (position deletes), partitioning, CTAS all work
select station_name, avg(measurement) from measurements group by 1;

From DuckDB, attach the same PG-hosted catalog over the postgres bridge and read/write the same tables and data files:

-- in DuckDB
INSTALL ducklake; INSTALL postgres; LOAD ducklake;

-- point ducklake at the PG-hosted catalog (no DATA_PATH needed if the
-- catalog's data_path is set on the PG side)
ATTACH 'postgres:host=pg.example dbname=lakehouse user=alice' AS dl (TYPE DUCKLAKE);

-- tables created from PostgreSQL show up here; writes land in the same catalog
SELECT * FROM dl.public.measurements;
INSERT INTO dl.public.measurements VALUES ('Berlin', 12.0);

Full usage, options, partitioning, role model, and limitations are in docs/ducklake.md. Supporting changes in pg_lake_engine and pg_lake_table (data-file stats, batch catalog inserts, field-id mapping, partition-spec catalog) are shared with the existing Iceberg path.

Limitations

• No partition spec evolution after CREATE TABLE. The spec is fixed at create time.
• No time-travel reads yet. lake_ducklake.snapshot is fully versioned, but nothing plumbs a historical snapshot_id into scans.
• No incremental (change-feed) reads. Scans always read the latest snapshot; there's no way to read just the rows changed between two snapshots.
• Inlined data is disabled. The extension forces data_inlining_row_limit = 0 so DuckDB always writes a Parquet file rather than materialising small INSERTs into a catalog table, because the FDW can't read inlined rows yet.
• CREATE VIEW from the DuckDB side persists lake_ducklake.view rows but isn't materialised as a PostgreSQL view, so those views aren't visible from PostgreSQL.
• DROP SCHEMA on the DuckDB side isn't propagated back to drop the PostgreSQL schema (intentionally, to preserve grants).
• DuckDB macros and the column_tag / tag / sort_info / column_mapping / name_mapping columns are stored but not yet surfaced or exercised by reads.

Test plan

• pytest suite for pg_lake_ducklake (basic, writes, CTAS, alter table, partitioning, snapshots, role grants, metadata spec, injection/crash)
• DuckDB interop suite (test_e2e_interop.py, test_duckdb_round_trip.py, test_concurrency_pg_vs_duckdb.py, test_interop_types_names_values.py) covering bidirectional read/write and DuckDB-driven compaction
• pg_lake_table DuckLake DDL/DML tests + isolation specs for concurrent DuckLake DDL and DML
• CI (build + full check)