rasterize: honor like.y orientation for ascending-y templates (#2170)

[brendancol]

Summary

• Detect like.y orientation once in _extract_grid_from_like().
• Carry the flag through to the coord-assignment site and flip the burned array on axis 0 right before reusing the template's coords. After the fix, result.sel(y=...) lines up with the geometry whether like.y ascends or descends.
• result.y still equals like.y byte-for-byte, so xr.align keeps working.

Closes #2170

Backend coverage

The flip is just out[::-1, :], which behaves the same on numpy, cupy, dask+numpy, and dask+cupy arrays.

Out of scope

There's a sibling issue for irregular like grids (non-uniform spacing). Not touched here.

Test plan

• New TestLikeYOrientation2170 in xrspatial/tests/test_rasterize.py, covering polygons, lines, and points across all four backends (GPU cases skip when CUDA isn't available).
• Regression test: result.sel(y=0.5, x=0.5) returns the burned value for both ascending and descending like.y.
• Round-trip: result.y == like.y and xr.align(result, like) still works.
• Explicit-bounds path still rebuilds descending coords (flip is correctly bypassed for any resized output).
• Full test_rasterize.py passes locally (199 passed, 2 skipped).

[brendancol]

PR Review: rasterize honor like.y orientation for ascending-y templates (#2170)

Blockers

None.

Suggestions

• xrspatial/rasterize.py:1968. y_ascending = height > 1 and float(y[-1]) > float(y[0]) only looks at the first and last samples. Fine for a monotonic 1D coord, but a non-monotonic or duplicate-valued like.y would be misclassified. The inline comment already defers the irregular-spacing case; a sentence noting monotonicity is assumed, or an np.all(np.diff(y) > 0) check, would make the contract explicit.
• xrspatial/rasterize.py:1978. _extract_grid_from_like now returns a 9-tuple and the call site unpacks positionally. A NamedTuple or small dataclass would scale better as future grid attributes get added. Out of scope for this fix.

Nits

• xrspatial/rasterize.py:2298. Descending-x templates would hit the same bug class as descending-y did before this fix. A short comment near the y-flip noting "x is assumed ascending; descending-x templates are not supported" would document the asymmetry for the next reader.
• xrspatial/tests/test_rasterize.py:2244. test_numpy_explicit_bounds_skips_flip asserts result.y.values[0] > result.y.values[-1]. Tightening to exact expected values (e.g. [3.5, 2.5, 1.5, 0.5]) would catch a regression where the bounds path produces an off-by-one coord centre.

What looks good

One detection site, one flip site, with comments at both explaining the image-vs-world convention. out[::-1, :] is backend-agnostic by construction. Tests hit all four backends and three geometry types, plus the xr.align round-trip and the explicit-bounds bypass. World-y selection asserts (result.sel(y=0.5, x=0.5)) target the bug directly rather than checking array indices. result.y is preserved byte-for-byte against like.y, which is what xr.align depends on. The height == 1 edge case falls out for free: the height > 1 guard makes y_ascending=False so the flip is a no-op.

[brendancol]

Follow-up review on 54fe792

All four findings from the first pass are addressed in the new commit.

Disposition

• Suggestion 1 (monotonicity contract). Fixed. The comment on y_ascending now states that monotonicity is assumed and that the irregular-spacing case is out of scope.
• Suggestion 2 (9-tuple unpacking). Fixed. _extract_grid_from_like returns a _LikeGrid NamedTuple. The call site in rasterize unpacks by attribute name.
• Nit 1 (x-axis asymmetry). Fixed. The same comment block now flags the descending-x case as out of scope so the asymmetry is explicit.
• Nit 2 (test assertion tightness). Fixed. test_numpy_explicit_bounds_skips_flip locks the exact y/x coord centres.

Verification

• pytest xrspatial/tests/test_rasterize.py passes locally (199 passed, 2 skipped).

Remaining concerns

None.