rasterize() silently ignores CRS mismatch between geometries and like template

[brendancol]

Describe the bug

rasterize(geometries, like=template) ignores any mismatch between the CRS of the input geometries and the CRS of the like template. _parse_input reads a GeoDataFrame's geometry and property columns but drops gdf.crs. When like is passed, _extract_grid_from_like carries the template's CRS through its non-dim coords (rioxarray's spatial_ref) and its attrs (attrs['crs']), and those land on the output.

So a lat/lon (EPSG:4326) GeoDataFrame can be rasterized against an EPSG:3857 template, and the output comes back tagged EPSG:3857 with no warning. The geometry coordinates were never reprojected, so the raster is wrong, but it carries an authoritative-looking CRS.

Expected behavior

When both the geometries and the like template carry a CRS, rasterize should compare them and raise when they disagree instead of emitting a mislabeled raster. A parameter should let callers turn the check off when they already know the coordinates line up.

Additional context

• _parse_input drops gdf.crs (xrspatial/rasterize.py around line 2764)
• _extract_grid_from_like keeps the template CRS via extra_coords and attrs (around lines 2954, 2970)
• output attrs propagate from like_attrs (around line 3462)

The accessor already does this elsewhere: _open_geotiff_windowed normalizes both CRS values through pyproj and raises on mismatch unless auto_reproject=True.