Stream indexes in fetch/gc/stats to optimize memory usage

[gwct]

Fixes four whole-genome scaling failures found on a 7.4 TB / 241-species MAF, where every command that read an index loaded it fully into memory:

• fetch -m scaffold tried to read a whole scaffold in one allocation. In the case of a single 597 GB read() it raised MemoryError, whose str() is empty (hence a blank [ERROR] in the log), and then reported "Wrote" and exited 0 with a 0-byte file, so downstream pipelines consumed the failure as success. Now streamed in bounded chunks, and scaffold failures fail the run.
• gc OOM-killed at 62 GB just parsing the 35 GB index. Streamed: peak went from linear (~32 GB extrapolated) to flat ~1.5 MB.
• stats had the same pattern; also streamed.
• fetch block mode built a dict per block (~67 GB at 233 M blocks). Regions are now sorted into index order and each worker streams its own span, using a binary search over the index file's bytes. On 20k real regions: 3.30 GB → 47 MB peak RSS, 8.9x faster, all 20,000 outputs byte-identical across none/gz/bgzip.

Two pre-existing bugs surfaced along the way: stats concatenated per-chunk block rows in lexicographic filename order (task10 before task2), scrambling block.tsv for any run with ≥10 chunks; and fetch's no-output accounting read the region's start coordinate instead of its block count, so any region starting at 0 was miscounted as empty (failing runs that had worked) while regions elsewhere finding zero blocks were counted as written.

Behavior changes to note: block mode now requires <maf>.scaffold.idx alongside the block index; non-overlap outcomes (no-overlap, missing scaffold, all-regions-empty, count/fraction thresholds) now warn and exit 0 instead of failing; stats' block.tsv row order changed for multi-chunk runs.

101 tests passing, including new streaming/scaffold-mode suites.

🤖 Generated with Claude Code (Opus 5)