geotiff: parallelise tile decode in _fetch_decode_cog_http_tiles (#1980)

[brendancol]

Summary

• The HTTP COG reader fetched tiles concurrently (issues Fetch COG tiles concurrently in HTTP path to mask RTT #1480, Fetch COG tiles concurrently in HTTP path to mask RTT #1487) but decoded them sequentially in a Python for loop. The sibling local-file path in the same module (_read_tiles) already parallelises decode whenever tile_pixels >= 64 * 1024 and n_tiles > 1; the HTTP path was structurally similar but never adopted the same gate.
• Mirror the local-path threshold and ThreadPoolExecutor in _fetch_decode_cog_http_tiles. Codec extensions (deflate, zstd, LZW) release the GIL inside their C implementations, so the pool overlaps decode work across cores. The placement loop that writes pixels into result stays serial to avoid contended writes.
• 5 new tests in test_cog_http_parallel_decode_2026_05_15.py: parallel + serial round-trip correctness, structural pool-instantiation check above the threshold, single-tile path skips the decode pool, _decode_strip_or_tile call count == n_tiles.

Pass 10 of /sweep-performance on the geotiff module. Closes #1980.

Test plan

• New tests pass: python -m pytest xrspatial/geotiff/tests/test_cog_http_parallel_decode_2026_05_15.py.
• Existing COG/HTTP suite passes: python -m pytest xrspatial/geotiff/tests/ -k 'cog or http' -> 262 passed.
• Full geotiff suite passes apart from two pre-existing failures (test_predictor2_big_endian_gpu_1517, test_size_param_validation_gpu_vrt_1776::test_tile_size_positive_works) flagged in prior sweep notes.

[brendancol]

PR Review: geotiff: parallelise tile decode in _fetch_decode_cog_http_tiles

Suggestions (should fix, not blocking)

• _reader.py:2747: the 64K-pixel threshold now appears in two places, _read_tiles (line 2017 pre-PR) and _fetch_decode_cog_http_tiles. Pull it up to a module-level constant so the comment about why the bound is inclusive lives in one spot.
• _reader.py:2755: _decode_one is only defined inside the if decode_in_parallel: branch, and the else branch inlines the same _decode_strip_or_tile call. _read_tiles defines _decode_one once above the branch and reuses it for both paths.

Nits

• _reader.py:2752: from concurrent.futures import ThreadPoolExecutor as _Pool. _read_tiles imports it under its real name; small consistency thing.

What looks good

• The gate matches _read_tiles exactly (n_tiles > 1 and tile_pixels >= 64*1024), so HTTP and local paths agree on when to spin up a pool.
• Pool is bounded by min(n_decode_tiles, cpu_count()) and cleaned up via with, so no leaked threads on decode error.
• Placement loop stays serial, so there's no race on result.
• Tests cover the parallel branch, the serial branch, pool instantiation count, and a monkey-patched call-count check on _decode_strip_or_tile that would catch a dropped or duplicated tile.
• Test fixtures use a real range-aware HTTP server rather than mocks.

Checklist

• No algorithmic change; output bytes match the serial path.
• Backend parity not applicable (HTTP COG path is numpy-only).
• NaN handling not applicable (decode is byte-exact).
• Edge cases covered (single-tile path skipped, threshold boundary tested).
• Dask chunk boundaries not exercised by this PR.
• No new materialisation or copies.
• No benchmark added; sweep notes cover the perf budget.
• README feature matrix N/A.
• Docstrings present.

I pushed a follow-up commit (164c524) applying the two suggestions and the nit.