Raster/vector join: cross-CRS footprint accuracy (densification, frame, antimeridian)

The raster–vector join reprojects the raster's four corners into the geometry operand's CRS and connects them with straight chords (the convex-hull footprint). Known limitations of this cross-CRS approximation:

- No edge densification. Reprojection turns straight edges into curves; a 4-corner hull under-/over-covers along them. Densifying each edge (~10 points is common, e.g. reusing the `st_segmentize` logic, with shared utilities moved to sedona-geometry) — or comparing in a geography with a meter tolerance — would be more accurate.
- Frame divergence from the scalar kernel. The join compares in the geometry operand's CRS; the scalar `RS_Intersects` kernel compares in the raster's CRS. The same predicate can therefore return different rows depending on whether the spatial-join optimizer fires. Same-CRS is exact and matches.

(Non-finite reprojected corners are handled defensively in the join so they yield no match rather than garbage.)

This tracks the SedonaDB side. The Sedona (Spark) side: https://github.com/apache/sedona/issues/3154.

The issue names no files or tests; first locate the raster–vector join implementation and the scalar RS_Intersects kernel. Compare their CRS and footprint handling, then determine which accuracy approach is intended; done means resolving the densification and frame-divergence limitations without producing invalid matches for non-finite corners.

Written by the indexing model from the issue text.