feat(go): bulk ingest via Volume + COPY INTO instead of per-row INSERT

[jatorre]

Summary

Replaces the per-row `INSERT` loop in `go/bulk_ingest.go`'s `executeIngest` with a streaming Parquet + COPY INTO path when a new `databricks.bulk.volume_path` option is set. Falls back to the per-row path when the option is unset, so this is purely additive and non-breaking.

Measured ~7,000× speedup at 100 K rows on a serverless Databricks SQL warehouse, with RSS bounded to ~11 MB regardless of source size.

Why

The current implementation issues one `INSERT INTO t VALUES (?, ?, ?)` per row through `db/sql.ExecContext`. Each call is a round-trip to the warehouse; in practice that pegs at ~0.7 rows/s, making `adbc_insert` impractical above a few hundred rows. The path I see commonly worked around outside the driver is "write Parquet to a Volume, COPY INTO" — this PR moves that into the driver so callers don't have to.

How

When `databricks.bulk.volume_path` is set, `executeIngest` switches to:

1. Open a Parquet writer over a local temp file (`pqarrow.NewFileWriter`).
2. Accumulate Arrow record batches from `s.boundStream` into the same file until the row count reaches `databricks.bulk.batch_rows` (default 20 000).
3. Close the writer; `PUT` the file via the Files API (`/api/2.0/fs/files{path}?overwrite=true`); issue `COPY INTO FROM (SELECT ... FROM '/Volumes/.../file.parquet') FILEFORMAT = PARQUET`; `DELETE` the staged file.
4. Repeat until the stream ends; final batch flushes any remainder.

Geometry handling:

• Walk the schema for `geoarrow.wkb` extension fields. CRS metadata is parsed in two shapes: the simple `{"crs":"EPSG:N"}` string AND DuckDB's `{"crs_type":"projjson","crs":{... "id":{"authority":"EPSG","code":N}}}` PROJJSON form.
• DDL emits `GEOMETRY()` for those columns (bare `GEOMETRY` is rejected on the SQL warehouses I tested).
• The COPY INTO transform projects each through `ST_GEOMFROMWKB(
, <srid_literal>)` so the staged BINARY rebuilds as a typed geometry on insert. The SRID has to be a SQL literal — passing it as a parquet column produces an untyped `GEOMETRY` whose schema can't be merged with the destination column (`DELTA_FAILED_TO_MERGE_FIELDS`).
5. A `databricks.bulk.geometry_columns` option (`"col:srid,col:srid"`) hints the driver for sources that emit BINARY without geoarrow.wkb metadata.

The existing `createTable` / `arrowTypeToDatabricksType` mapping has no geometry case (falls back to BINARY), so the new path uses a sister `createGeoAwareTable` that knows about the detected geo columns. I left the original codepath untouched.

Measurements

End-to-end through DuckDB's `adbc_scanner` calling `adbc_insert(handle, table, (SELECT ...))`. Source = synthetic POINT geometries. Warehouse warmed up before each timed run. Numbers from `tests/databricks-write-bench` and the in-driver harness in duckdb-warehouse-transfer (a CARTO-internal test workspace; happy to inline the harness here if useful).

Rows	Path	Throughput	RSS Δ
100 K	per-row INSERT (this PR's fallback / current main)	~0.7 rows/s (extrapolated, 1.5 s/row × 100K = ~42 h)	~10 MB
100 K	Volume + COPY INTO, no accumulator (one Parquet per Arrow batch)	748 rows/s	11 MB
100 K	Volume + COPY INTO, 20 K-row accumulator	5,110 rows/s	11 MB
100 K	Raw-SQL bench (large-batch ceiling, no DDL overhead)	6,324 rows/s	37 MB

So the patched driver is ~7,000× faster than the current main at 100 K rows, lands ~81 % of the raw-SQL ceiling, and uses ~30 % of its RAM. RSS is independent of source size because only one Parquet writer + one inflight HTTP body live at a time.

What's not changed

• Per-row INSERT path — left in place verbatim, runs when `databricks.bulk.volume_path` is unset.
• Read side / IPC reader / native geospatial read — orthogonal; this PR only touches the write side.
• Schema-merge edge cases for non-geometry types — the new path uses identical Arrow → Databricks DDL mapping for non-geo columns.

Things I'd like reviewer guidance on

1. Volume location. This PR requires the caller to provide a Volume path; the driver doesn't try to auto-derive one. An auto-default of e.g. `/Volumes///__adbc_staging` would be ergonomic but assumes that volume exists with the right ACLs. I'd rather fail loudly than silently fall back to per-row.
2. Accumulator policy. Currently row-count-based (`databricks.bulk.batch_rows`). Byte-size-based or hybrid would be more robust to varying row sizes; happy to add if preferred.
3. Error semantics on partial failure. If batch N fails, batches 0..N-1 are already committed — same as upstream's per-row path, where the same partial-commit behavior applies. Worth documenting more loudly?

Test plan

• `go build ./...` passes
• End-to-end smoke at 1 K, 10 K, 100 K rows lands the expected count, geom column ends up as `GEOMETRY(4326)`, and `ST_SRID(geom) = 4326` round-trips correctly
• Validation suite via `pixi run validate` — haven't run locally; will do once I see whether reviewers want this on a feature branch or merged with the existing options
• A unit test for `parseEPSGFromExtensionMetadata` (both shapes) and the COPY-INTO transform builder

[jatorre]

Note for reviewers: this stacks on #350 (Arrow-native geospatial). The DDL emitter uses the geoarrow.wkb type info from #350 to produce typed GEOMETRY(srid) columns, and the COPY INTO transform projects each geometry column through ST_GEOMFROMWKB(<col>, <srid_literal>). Recommend reviewing #350 first.

Just rebased onto current main. The diff still shows #350's contents because GitHub requires the base branch to live on the upstream repo — once #350 merges, this will narrow to the bulk-ingest changes (~640 lines, 5 files).