datalake_fdw: write path — INSERT to data files and a committed snapshot

Start with write.c and the AM insert callbacks: tuple_insert, multi_insert, and finish_bulk_insert. Review dependencies A, B2, and B4, then exercise the local-file functions for rolling, FileMeta, and abort logic. Done means the listed INSERT and COPY acceptance cases pass, including commit visibility, cleanup, metadata, size limits, and memory refusal.

Part of #2008. Letters (A, B0–B7, C, D, E) are the PRs listed there; this is C.

Scope

• write.c, the orchestration the format interface was written for: a writer per segment, rolling at the target size, Iceberg file naming under <location>/data/, a FileMeta per file (counts, sizes, per-column bounds and null counts) for commit.
• AM insert callbacks (tuple_insert, multi_insert, finish_bulk_insert): slots into the batch builder, field ids from the Iceberg schema into WriterOptions.field_ids.
• Segments write straight to object storage; the QD gathers every FileMeta and commits once at pre-commit. Abort anywhere leaves no data file (resource owner plus object delete) and no snapshot.
• COPY ... FROM uses the same path.
• With it: #1988 NUMERIC and #1990 timestamp units.

Out of scope

UPDATE/DELETE (E), partitioned tables (#1683 §2.3).

Depends on

A, B2, B4. Rolling, FileMeta and abort logic are testable with the local-file functions first.

Acceptance

• A multi-segment INSERT ... SELECT yields files readable by pyarrow and Spark; manifest counts and bounds match the data.
• Nothing visible before commit; abort leaves no files and no snapshot.
• Row group and target file size honoured within one row group.
• A large insert stays within gp_vmem_limit_per_query; refusal surfaces as ERRCODE_OUT_OF_MEMORY.