GeoParquet writer omits 'geo' file metadata for M/ZM geometry (both V1 and V2)

When writing GeoParquet via `COPY ... (FORMAT PARQUET, GEOPARQUET_VERSION ...)`, the `geo` file-level metadata key is omitted whenever the geometry has M or ZM dimensions. XY (and XYZ) writes include it correctly. GEOPARQUET_VERSION 'V1'` has reasonable behavior, as M wasn't defined, but it'd be great to update `'V2'` to the latest spec.

Repro (reproduced on duckdb 1.5.1 Python and 1.5.4 CLI, spatial extension current as of 2026-07):

```python
import duckdb, pyarrow.parquet as pq
con = duckdb.connect()
con.execute("INSTALL spatial; LOAD spatial")
con.execute("CREATE TABLE t AS SELECT ST_GeomFromText('LINESTRING ZM (0 0 1 2, 1 1 3 4)') AS geometry")
for ver in ('V1', 'V2'):
con.execute(f"COPY t TO 'zm_{ver}.parquet' (FORMAT PARQUET, GEOPARQUET_VERSION '{ver}')")
md = pq.ParquetFile(f'zm_{ver}.parquet').metadata.metadata or {}
print(ver, 'geo key present:', b'geo' in md) # False, False
con.execute("CREATE TABLE t2 AS SELECT ST_GeomFromText('LINESTRING (0 0, 1 1)') AS geometry")
con.execute("COPY t2 TO 'xy.parquet' (FORMAT PARQUET, GEOPARQUET_VERSION 'V2')")
print('XY geo key present:', b'geo' in (pq.ParquetFile('xy.parquet').metadata.metadata or {})) # True
```

Expected: the `geo` key is written for M/ZM data with `geometry_types` carrying the dimension suffix (e.g. `"LineString ZM"`), per the GeoParquet spec.

Found while auditing geoparquet-io against the geoparquet-testing corpus; we currently work around it by patching the metadata post-write (geoparquet/geoparquet-io#589).

Run the provided Python reproduction with the spatial extension and inspect the GeoParquet metadata path reached by COPY ... (FORMAT PARQUET, GEOPARQUET_VERSION ...). Compare V1 and V2 output for XY, XYZ, M, and ZM geometries, and use the geoparquet-testing corpus as a reference. Done means the file-level geo key is present for M/ZM data with geometry_types including the dimension suffix.

Written by the indexing model from the issue text.