test(integration): RS_Envelope, RS_ConvexHull, RS_PixelAs* parity (item-level-CRS geometry in the harness)

[james-willis]

Completes parity coverage of the geometry-returning raster functions, closing out the batch #1264 unblocked: RS_Envelope, RS_ConvexHull, RS_PixelAsPoint, RS_PixelAsCentroid, RS_PixelAsPolygon — one file per function, every case probed on both engines first.

Harness: item-level-CRS geometry (first commit)

These five functions return geometry whose CRS can vary per row, which SedonaDB represents as struct<item: geoarrow.wkb, crs> — the tuple stringifier could not cast it ("Unsupported cast from struct"). result_to_tuples now unwraps the struct and renders the geometry child as WKT like any other geometry column (parent nulls propagated via pc.struct_field); the per-item crs field has no counterpart in the other engine's result and stays covered through the RS_CRS suite. RS_WorldToRasterCoord was unaffected because its pixel-space output carries no CRS.

What the probes found

Mostly good news — four of the five functions agree exactly, anchored with exact WKT:

• RS_ConvexHull: identical ring on both engines (clockwise from the upper-left corner), with and without a raster CRS.
• RS_PixelAsPoint / Centroid / Polygon (in grid): both engines read the pixel coordinate 1-based; corners, centroids, and footprints match string-for-string.
• RS_PixelAsCentroid / Polygon (out of grid): both engines extrapolate along the geotransform, identically — anchored.

Two divergences, xfail-cataloged:

• RS_Envelope ring order: same rectangle, opposite winding — SedonaDB counter-clockwise from the lower-left, Sedona Spark clockwise. (Spark's envelope winding also differs from Spark's own convex-hull winding.)
• RS_PixelAsPoint out of grid: SedonaDB extrapolates ((0, 0) → POINT (98 503)); Sedona Spark raises IndexOutOfBoundsException ("Specified pixel coordinates (0, 0) do not lie in the raster") — even though Spark's own RS_PixelAsCentroid and RS_PixelAsPolygon extrapolate happily. An internal inconsistency on the Spark side.

Full suite: 188 passed, 103 xfailed.

With this, every dual-engine RS_ function has a parity file except RS_Values (list-column results; its coordinate-array overload also has no SQL spelling both engines parse) and RS_AsGeoTiff (binary output, no shared round-trip SQL).

[paleolimbot]

Integration tests look great! I'm not sold on the handling of item crs in the tuples converter, but also our current handling is not great either.

[paleolimbot]

In this particular context, item crs could come back as {"item": <wkt>, "crs": <crs>} or (<wkt>, <crs>). I am not sure that ditching the CRS is a good idea for this specific function (you could always issue a separate query with just the geometry field if this is what you wanted to test?)