Streaming reproject fallback has zero test coverage

[brendancol]

reproject() has five execution paths: in-memory numpy, in-memory cupy, dask, dask+cupy, and a streaming fallback that kicks in when the source is over 512 MB and dask can't be imported. The first four are covered in test_reproject.py. Nothing runs the streaming one: _reproject_streaming, _process_tile_batch, and _parse_max_memory (xrspatial/reproject/__init__.py) never execute under pytest.

The path has its own tile-job construction, a ThreadPoolExecutor batching loop with a serial fallback, mosaic assembly from (row_offset, col_offset, tile) triples, and the max_memory parser. An off-by-one in the assembly offsets, or a parser regression, would not turn any test red.

The existing max_memory tests (test_reproject_max_memory_string_arg / test_reproject_max_memory_int_arg) push a 32x32 raster through reproject(), which stays on the in-memory path. _parse_max_memory only runs when the streaming branch is selected, so those tests never reach it.

Proposed tests (test-only):

• Call _reproject_streaming directly on a small raster and compare against the in-memory numpy output for the same grid: multi-tile threaded run, serial run (max_memory small enough to disable the thread pool), single-tile run.
• _parse_max_memory unit cases: None default, KB/MB/GB/TB suffixes, int passthrough, bare numeric string.
• A strict xfail pinning the 3-D crash tracked in _reproject_streaming crashes on 3-D (multi-band) sources #3100.

I checked locally: the 2-D streaming output matches the in-memory result, so this is a coverage gap rather than a behaviour bug.