rasterize: drop stale transform/res from like.attrs when grid is overridden

[brendancol]

Closes #2251

Summary

• When rasterize(geoms, like=template, ...) is called with an explicit
  bounds, width/height, or resolution that reshapes the output
  relative to the template, the inherited attrs['res'] and
  attrs['transform'] describe the template's grid, not the actual
  output. get_dataarray_resolution prefers attrs['res'] over
  computing from coords, so downstream slope/aspect/proximity callers
  silently used the wrong cellsize.
• Fix strips res / transform from the propagated like.attrs when
  the output grid no longer matches the template (the existing
  reuse_like_coords flag already captures exactly this condition).
  crs, spatial_ref, and the nodata triplet still propagate.
• 9 new tests in TestLikeStaleGridAttrs2251 cover bounds /
  width-height / resolution overrides, matching-size keeps the attrs,
  get_dataarray_resolution consistency, and parity across numpy /
  cupy / dask+numpy / dask+cupy backends.

Test plan

• New tests in TestLikeStaleGridAttrs2251 pass (9/9, all 4 backends)
• Existing TestMetadataPropagation tests still pass (13/13)
• Full test_rasterize.py suite passes (224 passed, 2 skipped)
• Other rasterize tests pass (test_rasterize_accuracy,
  test_rasterize_all_touched_supercover_2169,
  test_rasterize_coverage_2026_05_17,
  test_rasterize_gpu_race_2167,
  test_rasterize_tile_props_slice_2020: 153/153)
• Callers pass (test_zonal, test_polygon_clip, test_accessor:
  173/173)

Found by /deep-sweep metadata propagation audit (Cat 1, HIGH).

[brendancol]

PR Review: rasterize -- drop stale transform/res from like.attrs when grid is overridden

Summary

I read through the fix in xrspatial/rasterize.py lines 3216-3227. The guard if like_attrs is not None and not reuse_like_coords does the right thing: it drops res and transform exactly when the output grid was reshaped relative to like. Reusing the existing reuse_like_coords flag is the right call -- there's no need to invent a second predicate for the same condition.

I also checked one thing that worried me: out_attrs = like_attrs followed by pop could mutate the caller's template attrs if like_attrs were a live reference. It isn't. _extract_grid_from_like returns attrs=dict(like.attrs) at line 2846, so it's already a copy.

get_dataarray_resolution in xrspatial/utils.py:483 does prefer attrs.get('res') over calc_res, so the symptom the PR describes is real and not theoretical.

Blockers

None.

Suggestions

None.

Nits

• xrspatial/rasterize.py:3225: one slightly over-eager edge case. If a caller passes bounds= that exactly matches the template's bounds (with matching width/height), bounds_explicit=True so reuse_like_coords is False, and res/transform get stripped even though the grid is effectively identical. That said, the rebuilt linspace coords may drift by a ulp or two, so the strip is still arguably correct. Not worth changing; maybe worth a sentence in the comment if someone touches this block again.

What looks good

• 9 tests, and they hit the three override paths plus the matching-size case plus the get_dataarray_resolution end-to-end symptom plus dask/cupy/dask+cupy parity.
• The strip-case tests assert crs still propagates, which keeps anyone from later "fixing" this by stripping everything.
• All four backends funnel through the same return statement, so one 2-line patch covers all of them.
• The inline comment at lines 3216-3224 explains the why, not the what. Future-me will appreciate that.