rasterize: reject partial width/height overrides instead of silent ignore

[brendancol]

Closes #2569.

Summary

• rasterize(..., like=template, width=W) used to silently drop width and return the template's size. Now it raises ValueError naming the missing dimension.
• The same check applies without like: passing only one of width/height (with or without resolution) now raises with a clear message instead of falling through to the next branch.
• Docstring updated so the both-or-neither contract is part of the documented API.

Why ValueError rather than deriving the missing dim

When like is given, the bounds also come from the template. Filling in the missing dimension from aspect/resolution would force the x and y pixel sizes to disagree, and the output coords would no longer match like. A loud error is the less surprising behaviour.

Backend coverage

This is in the front-end argument resolver, before any backend dispatch. Same behaviour for numpy / cupy / dask+numpy / dask+cupy.

Test plan

• like + both width and height honored (size matches the explicit args)
• like + only width raises with "height was not"
• like + only height raises with "width was not"
• like + neither uses the template grid bit-exactly
• No like: only-width-plus-resolution raises
• No like: only-height raises
• Full xrspatial/tests/test_rasterize.py still passes (215 passed, 2 skipped)

[brendancol]

PR Review: rasterize: reject partial width/height overrides instead of silent ignore

Blockers

None.

Suggestions

None.

Nits (optional)

• xrspatial/rasterize.py:3214-3228: the partial-dims check runs after _parse_input and the inferred-bounds computation. A caller passing only width with a large geometry set pays the bbox-inference cost before the error fires. Moving the check up to right after argument unpacking would fail faster on the unhappy path. Strictly cosmetic; the practical impact is small.
• xrspatial/rasterize.py:3228: the error message ends with "use resolution or like to size the output". Resolution alone still needs bounds (explicit or inferable from geometries), so the phrasing slightly oversells what resolution covers. Something like "pass both width and height together, or omit both and supply resolution or like" would avoid the implication.

What looks good

• (width is None) != (height is None) is the clean XOR form and reads well.
• The error message names the missing dimension, which is exactly what the issue asked for.
• Tests cover all four cases from the issue (both / only-width / only-height / neither) plus a no-like variant that catches a related silent fall-through.
• Docstring updates on width, height, and like keep the documented contract aligned with the runtime check.
• Full test_rasterize.py still passes (215 passed, 2 skipped). No regression.

Checklist

• Algorithm matches reference/paper (N/A, argument validation only)
• All backends behave consistently (check runs before backend dispatch)
• NaN handling correct (N/A)
• Edge cases covered by tests
• Dask chunk boundaries handled correctly (N/A)
• No premature materialization
• Benchmark exists or not needed (validation-only)
• README feature matrix (no change required)
• Docstrings present and accurate

[brendancol]

Follow-up review (after ce0acc1)

Both nits from the previous review have been addressed:

• The partial-dims check now sits right after merge validation, before _extract_grid_from_like and _parse_input. The error fires before any geometry or template work, so a caller passing only width no longer pays the bbox-inference cost.
• The error message now reads "pass both width and height together, or omit both and supply resolution or like to size the output", so the phrasing no longer suggests resolution alone is sufficient.

Status

• Blockers: none
• Suggestions: none
• Nits: none

Tests still green (221 passed, 2 skipped). Ready from the review side.