Guard stream_order_mfd() against unbounded memory allocations (#1349)

[brendancol]

Fixes #1349.

stream_order_mfd allocated several H*W working arrays in its eager numpy and cupy backends and a (8, H, W) float64 fractions copy on top, with no upfront check that the result will fit in memory. A 50000x50000 raster wants ~262 GB on the CPU path, so the failure mode was an OOM kill rather than a clean Python exception.

This adds the per-module memory guard helpers (_BYTES_PER_PIXEL, _GPU_BYTES_PER_PIXEL, _available_memory_bytes, _available_gpu_memory_bytes, _check_memory, _check_gpu_memory) used across the rest of the hydro series and wires them into the public dispatch before any allocations.

Bytes per pixel

CPU peak working set, Strahler worst case:

array	dtype	B/px
frac input copy (8,H,W)	float64	64
stream_mask	int8	1
order	float64	8
in_degree	int32	4
max_in	float64	8
cnt_max	int32	4
queue_r	int64	8
queue_c	int64	8

Total ~105 B/px.

GPU peak working set ~101 B/px. Use 105 B/px for both as a conservative budget.

Behaviour

• numpy and cupy paths now raise MemoryError with a clear message when projected use exceeds 50% of available memory.
• dask paths skip the guard. Per-tile allocations are bounded by the chunk size and the dask scheduler handles spilling.
• The error message names the grid dimensions and points users at dask for out-of-core processing.

Tests

Five new tests in TestMemoryGuard:

• numpy path raises with patched memory
• normal-size raster passes the guard
• dask path bypasses the guard
• error message mentions dimensions and dask
• cupy path raises with patched GPU memory

Full file: 14 tests pass. Full hydro suite: 643/644 pass; the one failure is the known test_stream_link_dask_temp_cleanup flake unrelated to this change.

Companion issues

Same pattern as #1318 / #1319, #1321 / #1324, #1322, #1328 / #1331, #1333, #1337 / #1341, #1343.