Make geodesic slope memory guard backend-aware for dask

[brendancol]

Closes #2765

What changed

• slope(method='geodesic') sized its memory guard against the full raster before dispatch. That's correct for eager NumPy/CuPy (they build a (3, H, W) float64 stack up front), but wrong for dask, which streams that stack chunk by chunk via map_overlap. The full-raster check rejected large-but-chunked rasters that would run fine.
• Added _check_geodesic_memory_backend_aware: eager backends keep the full-raster check; dask backends check the largest spatial chunk plus its 1-cell map_overlap halo (+2 per spatial dim). A single whole-raster chunk has no memory advantage and is still rejected.

Backend coverage

The guard runs before dispatch, so the new path covers all four backends: numpy and cupy use the eager full-raster check; dask+numpy and dask+cupy use the per-chunk check. aspect(method='geodesic') has the same eager-only guard and is left for a separate change to keep this PR scoped to the reported finding.

Test plan

• Eager raster too large for available RAM still raises MemoryError (existing test).
• Same raster chunked small enough is allowed through (new dask test).
• Dask array with a single whole-raster chunk is still rejected (new dask test).
• test_geodesic_slope.py passes (23 tests).
• test_geodesic_aspect.py still passes (shared geodesic.py untouched in behaviour).

[brendancol]

PR Review: Make geodesic slope memory guard backend-aware for dask

Blockers (must fix before merge)

None.

Suggestions (should fix, not blocking)

• aspect.py:427 has the same eager-only guard (_check_geodesic_memory(rows, cols)) and so has the same bug. The PR scopes itself to slope per the issue and says so in the body, which is fair. File a follow-up so the aspect path doesn't quietly keep the wrong behavior.

Nits (optional improvements)

• geodesic.py: the guard uses max(row_chunks) and max(col_chunks) independently, so the two maxima can come from different chunks and the bound can slightly overestimate the largest real chunk. That over-rejects rather than under-rejects, which is the safe direction for a memory guard, so it's fine as-is. Noting it so the conservatism is on record.

What looks good

• The +2 per spatial dim matches the depth-1 map_overlap halo. The chunk function allocates against the haloed chunk shape, so the byte budget tracks the real peak.
• getattr(data, "chunks", None) splits eager (no chunks attribute) from dask without importing dask in the guard.
• Tests pin all three behaviors: eager rejected, chunked allowed, single whole-raster chunk still rejected. The chunked test first checks that the same raster is rejected eagerly, which makes the contrast explicit.

Checklist

• Contract matches the issue: yes
• Both backend classes covered: yes (eager full-raster, dask per-chunk)
• NaN handling: unchanged, n/a
• Edge cases tested: empty chunk tuple guarded with ... else 0
• Dask chunk boundaries: yes, +2 halo accounted for
• No premature materialization: guard reads .chunks metadata only, no compute
• Benchmark: not needed (cheap metadata check)
• README matrix: not needed (no API change)
• Docstrings: present on the new helper

[brendancol]

Review follow-up: the aspect.py suggestion is tracked as a separate issue (#2783) to keep this PR scoped to slope. The max() * max() nit is intended (conservative over-rejection is the safe direction for a memory guard); no change. No code changes resulted, so the existing review stands.