fl_dem_aoi tests lose the CRS on GDAL 3.12 / PROJ 9.7, failing R CMD check #98

If we do it: the R-CMD-check workflow in #97 can merge green, and fl_dem_aoi()'s grid pinning is known to hold on current GDAL/PROJ builds. If we never do: #97 stays open and flooded has no CI; if the failures reflect real behaviour on newer PROJ, AOI grids placed on such a machine may differ from the pinned ones.

Problem

The first R-CMD-check run on #97 (ubuntu-latest, Ubuntu 26.04: GDAL 3.12.2, PROJ 9.7.1, GEOS 3.14.1) errors in three tests of test-fl_dem_aoi.R, each with the same message:

── Error ('test-fl_dem_aoi.R:371:5'): the mock's 1.3 m step crosses a cell boundary at every offset (#78)
── Error ('test-fl_dem_aoi.R:482:5'): fl_dem_aoi places the grid the same for an AOI in a third CRS, whichever PROJ sf links (#78)
── Error ('test-fl_dem_aoi.R:498:5'): fl_dem_aoi pins an AOI's grid when the source -> target pair has no pin (#78)
Error in `st_transform.sfc(st_geometry(x), crs = crs, ...)`: cannot transform sfc object with missing crs

The same file passes (129 expectations, 0 failures) on a machine with GDAL 3.8.5, PROJ 9.5.1, GEOS 3.13.0. All three go through the datum-shift mock (with_sf_datum_shift()); not yet known is whether the mock or fl_dem_aoi() loses the CRS on the newer stack.

Proposed Solution

Reproduce on the newer stack (print the geometry's CRS before the failing st_transform() on a CI run), fix the cause, and #97 can merge.

Relates to #97