RS_ raster predicates: transform geometry into the raster CRS for cross-CRS comparison (match SedonaDB)

For a cross-CRS raster/geometry predicate, `RS_Intersects`/`RS_Contains`/`RS_Within` currently transform **both** operands into WGS84 (EPSG:4326) and compare there. Because the raster footprint is reprojected to WGS84 with straight chords between its four corners, its edges are approximated — this is the motivation for densifying the footprint (#3154).

SedonaDB's RS_ predicate implementation instead transforms the **geometry into the raster's CRS** and compares in the raster's native frame. A raster footprint is exactly a straight-edged quadrilateral in its own CRS (pixel→world is affine, and affine maps lines to lines), so keeping the raster in its native CRS makes its footprint exact and moves the reprojection onto the (usually smaller, often point) geometry. That is more accurate for the common point-in-raster case, and it removes the need to densify the raster footprint's edges at all.

Consider matching this behavior: transform the geometry into the raster's CRS rather than reprojecting both to WGS84.

Related: this is largely an alternative to the raster-side densification in #3154 (keeping the raster native avoids the curved-edge approximation entirely), and to the SedonaDB-side frame-divergence discussion in apache/sedona-db#1076.

Start with the RS_Intersects, RS_Contains, and RS_Within implementations and trace their cross-CRS handling. Compare that behavior with SedonaDB's predicate implementation and the discussion in apache/sedona-db#1076. Done means the geometry is transformed into the raster's CRS for comparison while the raster remains native; assess whether this makes #3154's densification unnecessary.

Written by the indexing model from the issue text.