test(integration): RS_ZonalStats and RS_ZonalStatsAll parity

[james-willis]

Parity coverage for RS_ZonalStats and RS_ZonalStatsAll, probe-first, one module per function. Branches off main, independent of the other open parity PRs.

What agrees (32 passing tests, every anchor exact)

The headline probe finding: every statistic matches numpy's exact double bit-for-bit on both engines — including mean, variance, and stddev — so there is no tolerance anywhere in the module. The shared conventions the anchors pin:

• sample (ddof=1) variance and stddev;
• even-count median averages the two middle values; odd-count is the exact middle element;
• mode ties break toward the higher value (probed with planted 2-vs-2 ties);
• avg/average/sd aliases accepted by both;
• exclude_no_data defaults true (a planted in-roi nodata pixel drops from the count) and can be disabled;
• all_touched selects a centre-free sliver that the default centre-in rule ignores;
• a disjoint roi yields NULL under the default lenient behavior;
• both engines refuse strict-disjoint (lenient=false), unknown statistics, and out-of-range bands (0 and beyond) — contrast the RS_BandNoDataValue getter, where SedonaDB returns NULL for out-of-range bands.

RS_ZonalStatsAll is compared field by field — s['field'] parses in both dialects — because the whole-struct schemas differ (SedonaDB types count as nullable Int64; Sedona Spark returns non-nullable Doubles throughout) and the harness stringifies scalar columns, not structs.

What diverges (3 xfails)

• Band-less forms on a multi-band raster (both functions): SedonaDB requires the band argument (documented as deliberate in the kernel); Sedona Spark defaults to band 1.
• CRS-carrying roi on a CRS-less raster: SedonaDB refuses ("geometry has a CRS but the raster does not"); Sedona Spark computes as if they matched.

Line and diagonal rasterization (ported from apache/sedona GH-3118)

The traversal-rewrite fixtures from RasterizationTests are ported verbatim (unit-pixel grids and WKTs kept as-is — the near-corner coordinates are float-tuned to them), expressed as RS_ZonalStats(count) over LINESTRING rois so the burned-cell set is what's compared. Every line runs forwards and reversed against one anchor, pinning GH-3118's direction independence along with parity; the bottom-up (positive scaleY) grid agrees under both flags; and the coastline multipolygon lands exactly on the 1738/1842 counts Sedona pins to GDAL/rasterio.

Probing these surfaced two new Spark line-roi divergences, xfail-cataloged with apache/sedona#3322:

• all_touched is ignored for line geometries — the count never changes with the flag, where SedonaDB includes every touched cell, matching rasterio;
• the default rule burns every traversed cell where GDAL burns only centre/diamond crossings — corner-crossing segments mask this because their traversal and diamond counts coincide, which is why GH-3118's own fixtures agree by default.

One corner-tangent case is anchored to the engines' shared 13 rather than this suite's rasterio wheel (which says 14): whether a cell merely touched at a lattice corner counts under all_touched is a GDAL-version-sensitive tie, noted in the test.

Verification

integration/spark-parity locally: the two modules run 41 passed, 7 xfailed (pyspark 4.0.4, Sedona 1.9.1); CI runs the parity lane on this branch.