[GH-3120] Fix rasterization at grid-aligned endpoints

[jiayuasu]

Did you read the Contributor Guide?

• Yes, I have read the Contributor Rules and Contributor Development Guide

Is this PR related to a ticket?

• Yes. Closes allTouched/line rasterization can burn a corner-touched pixel at grid-aligned vertices (differs from GDAL by one pixel) #3120.

What changes were proposed in this PR?

Line rasterization derived both endpoint cells with floor(). When an endpoint mapped exactly to a pixel grid line and the segment extended toward the negative side, floor() selected the adjacent positive-side cell even though the segment never entered it. At lattice-corner endpoints, that cell could also be unreachable by the traversal, causing it to continue until its safety bound and burn an unrelated diagonal streak.

This patch selects an endpoint cell from the side containing the segment interior, but only when the computed pixel coordinate is exactly integral. Nearby nonintegral coordinates are unchanged, and axes with no extent retain the existing half-open floor() convention.

The scope is deliberately limited. This PR does not introduce coordinate snapping or tolerances, reinterpret decimal or affine-generated coordinates, or change segment clipping and extreme-coordinate behavior.

The existing rasterization test class is renamed from RasterizationTests to RasterizationTest so Maven Surefire discovers it under the repository's current default patterns.

How was this patch tested?

Coverage includes:

• grid-line endpoints when arriving, leaving, and reversing a segment;
• lattice-corner termination without a traversal streak;
• a shared polyline apex on a corner;
• horizontal and vertical segments lying on grid lines;
• Math.nextUp and Math.nextDown coordinates to verify that nearby values are not snapped;
• polygon and multipolygon integration cases, including rasterio/GDAL parity fixtures.

Commands run locally:

• mvn -pl common test — 1,285 tests passed;
• mvn -pl spark/common -Dspark=3.5 -Dscala=2.12 -Dtest=NoSuchTest -Dsurefire.failIfNoSpecifiedTests=false -Dsuites=org.apache.sedona.sql.rasteralgebraTest test — 166 tests passed;
• repository pre-commit hooks and git diff --check passed;
• python3 -m py_compile tests/sql/test_rasterize_parity.py passed. The full Python parity suite was not run in this checkout because pytest is not installed.

Did this PR include necessary documentation updates?

• Yes. RS_AsRaster.md now documents endpoint-only line/polygon contacts and preserves the existing POINT behavior.

[jiayuasu]

Follow-up work intentionally kept out of this PR:

• RS_AsRaster segment clipping drops crossings and loses grid-line sidedness #3255 — robust, direction-independent segment/window clipping, including both-outside crossings and clipped-endpoint sidedness.
• Define deterministic floating-point grid-boundary semantics for RS_AsRaster #3256 — define deterministic floating-point grid-boundary semantics for decimal, affine-derived, large-origin, and adjacent-representable coordinates.

The clipping issue should land first. This PR remains limited to endpoint-cell selection when the computed pixel coordinate is already exactly integral.