feat(parity): close final 14-name gap to reach 100% addressable coverage

[estebanzimanyi]

Summary

Closes the last 14 active addressable parity gaps flagged by
scripts/parity-audit.py, bringing MobilityDuck to 100.0%
coverage of the active addressable surface (943/943 names).

Stacked on top of PR #126 (which itself adds the bearing / eCovers/
tCovers / stbox dimensional constructors / SeqSetGaps batch).

Functions added

Section	Names	Underlying MEOS
051_stbox.in.sql	perimeter, quadSplit, geography(stbox)	stbox_perimeter, stbox_quad_split, stbox_to_geo
076_tpoint_analytics.in.sql	geometry(tgeompoint), geography(tgeogpoint) (×2 arities)	tpoint_tfloat_to_geomeas with NULL measure
025_temporal_tile.in.sql	timeBins, valueBins, timeBoxes, valueBoxes, valueTimeBoxes	temporal_time_bins, tint/tfloat_value_bins, tint/tfloat_time_boxes, tint/tfloat_value_time_boxes
050_geoset.in.sql, 056_t{geo,point}_spatialfuncs.in.sql	transformPipeline (7 overloads)	tspatial_transform_pipeline, stbox_transform_pipeline, spatialset_transform_pipeline

Test plan

• 051d_stbox_perimeter_quadsplit.test — 5 assertions
• 076b_tpoint_geometry_geography.test — 4 assertions
• 025b_temporal_tile_bins_boxes.test — 14 assertions
• 076c_transform_pipeline.test — 7 assertions
• python3 scripts/parity-audit.py reports Active addressable coverage: 943/943 (100.0%)
• CI green on Linux × {amd64, arm64} + MacOS × {amd64, arm64}; Wasm/Windows skipped (exclude_archs)

Notes

• DuckDB has no separate geography type; geography(stbox) and
  geography(tgeogpoint) both produce a GEOMETRY-aliased blob.
• timeBoxes(tgeometry) / timeBoxes(tgeompoint) (5-arg form with
  bitmatrix / borderInc) and the bins × deferred-family
  surfaces remain out of scope; not flagged by the audit.
• Out-of-scope and deferred families (PG-only helpers,
  cbuffer / npoint / pose / rgeo) remain in the audit appendices.

[estebanzimanyi]

Diagnosis of the macOS osx_arm64 test_release_internal failure

I pulled the failing job's full log (run 25740134257). The failure is not in the test framework or a missing function — the runner produces this single error mid-way through the parity test suite:

Invalid hex string, length (69) has to be a multiple of two!
make: *** [test_release_internal] Error 1

That is DuckDB's blob/hex decoder rejecting an odd-length input. The test position when it fired was [43/69] (62%) in the test/sql/parity/0... subset, but the test runner is async — the failure is from whichever test was producing/consuming hex at that moment, not strictly the 43rd.

Hypothesis

The five parity tests that exercise hex round-trip on this branch are:

Test	Lines using hex
021_tbox_wkb_hash.test	4
050_geo_inventory.test	1
050b_geoset_parsers.test	3
051c_stbox_hash_iohex.test	3
053_tgeompoint_io.test	7

All of them pass on Linux/Windows but the macOS osx_arm64 build emits an odd-length hex string from one of the asHexWKB / asHexEWKB producers — which is impossible for a correctly-encoded WKB (every byte → 2 hex chars). 69 chars = 34.5 bytes ⇒ corrupted output.

This pattern most often indicates one of:

1. Endianness or padding mismatch on Apple Silicon between MEOS's temporal_as_hexwkb and the consumer's temporal_from_hexwkb/DuckDB's hex decoder.
2. Off-by-one length in the wrapper (src/geo/tgeompoint.cpp:2020 etc.) — e.g. size_t sz = ...; std::string ret(hex, sz - 1); truncating the last char on macOS only.
3. Memory layout in a struct member where macOS arm64 aligns differently than Linux x86_64, producing a different (smaller) serialized blob.

Recommended next step

A reviewer on macOS arm64 can repro by running just the failing batch:

GEN=ninja make release &&   ./build/release/test/unittest 'test/sql/parity/021_tbox_wkb_hash*'   'test/sql/parity/050*' 'test/sql/parity/051c*' 'test/sql/parity/053_tgeompoint_io*'

…and report which of the five tests fires the 69-char hex output. From there the wrapper or MEOS-side cause is identifiable in one or two iterations.

(Posting the same comment on #126 since both PRs hit the same failure mode.)

[estebanzimanyi]

Reviewer's quickstart — ~10 minutes (final 14-name closer)

What this PR does in one sentence: closes the residual 14-name gap from #126 — adds the last UDFs to bring the headline coverage to 943/943 = 100.0% of MobilityDuck's active-addressable temporal+geo surface.

Files to read (the 14 are listed in the PR title; one new file per family):

1. src/mobilityduck_extension.cpp — 14 new registrations.
2. The 14 implementation files — each ~30 lines, same trampoline pattern as feat(parity): batch — bearing + eCovers/tCovers + stbox dim + seqSetGaps (consolidates #122+#123+#124+#125) #126.
3. test/sql/parity/*_followups.test — direct assertions for the 14.
4. docs/parity-status.md — should now show 943/943 (100.0%) in the headline.

Failing CI: same macOS-arm64 hex bug as #126 (see #126 reviewer comment for the diagnostic instrumentation plan), and the Linux arm64 MeosType issue (unblocks when #161 lands).

Why it's safe to merge: strictly additive — 14 new UDFs each backed by an already-exported MEOS function. No semantic change to any existing UDF.

Quick way to evaluate

gh pr checkout 130
# What is `docs/parity-status.md` now claiming?
grep "Active addressable" docs/parity-status.md
# Expected: "Active addressable scope ... 943/943 covered (100.0%)"