RS_RasterToWorldCoord*/RS_WorldToRasterCoord* are 0-based; Sedona Spark, PostGIS, and RS_PixelAs* are 1-based

`RS_RasterToWorldCoord`/`X`/`Y` and `RS_WorldToRasterCoord`/`X`/`Y` treat pixel coordinates as **0-based**, while Sedona Spark (following PostGIS) is **1-based**. Every result is exactly one pixel off, including extrapolation outside the grid. On the standard parity grid (origin (100, 500), 2x3 pixels):

| query | SedonaDB | Sedona Spark |
|---|---|---|
| `RS_RasterToWorldCoordX(rast, 1, 1)` | 102 | 100 |
| `RS_RasterToWorldCoordY(rast, 1, 1)` | 497 | 500 |
| `RS_WorldToRasterCoordX(rast, 100, 500)` | 0 | 1 |
| `RS_WorldToRasterCoordY(rast, 100, 500)` | 0 | 1 |
| `RS_WorldToRasterCoordX(rast, 90, 505)` | -5 | -4 |

Meanwhile `RS_PixelAsPoint`/`Centroid`/`Polygon` are **1-based in both engines** (`RS_PixelAsPoint(rast, 1, 1)` → `POINT (100 500)` on both) — so SedonaDB is also internally inconsistent between its coordinate mappers and its pixel-geometry functions. Neither kernel documents a basis choice (`rs_rastercoordinate.rs`, `rs_worldcoordinate.rs`).

Surfaced by the `integration/spark-parity` suite; the coordinate-mapper modules xfail-catalog this divergence referencing this issue. Proposal: align the mappers to 1-based (Spark/PostGIS convention, and consistent with `RS_PixelAs*`), or document 0-basing loudly if it is deliberate.

Read rs_rastercoordinate.rs and rs_worldcoordinate.rs, then run the integration/spark-parity suite and review its xfail references to this issue. Determine with maintainers whether the mappers should use the 1-based convention or retain 0-based behavior. Done means the chosen convention is consistent with the related RS_PixelAs* functions, parity expectations are updated, and the basis is documented if needed.

Written by the indexing model from the issue text.