contours and polygonize disagree on CRS resolution from the same raster

[brendancol]

Describe the bug

contours(..., return_type='geopandas') resolves the output CRS only from agg.attrs['crs']. Both CRS sites in xrspatial/contour.py use agg.attrs.get('crs', None): the all-non-finite early return (line 656) and the main geopandas return (line 688). If a raster carries its georeferencing under attrs['crs_wkt'] or via raster.rio.crs instead, contours drops it and returns an unprojected GeoDataFrame.

polygonize, the other raster-to-vector function, already has a fuller resolver: _detect_raster_crs in xrspatial/polygonize.py (line 793). Its order is:

1. attrs['crs']
2. attrs['crs_wkt']
3. raster.rio.crs
4. None

So the two entry points disagree on how they pick up georeferencing from the same input. A raster that polygonizes with a CRS can come out of contours without one.

Expected behavior

contours should resolve the output CRS the same way polygonize does, so both georeference identically from the same raster. There's no import cycle between the two modules, so the fix can reuse _detect_raster_crs directly at both CRS sites.

Additional context

Found during a code review of the contours module.