perf(svar2): consume genoray's sparse range stream in the writer

[d-laub]

Closes #405.

What

_write_from_svar2 built its region-CSR range cache by materializing genoray's dense (samples, ploidy, regions, 2) chunk and then throwing almost all of it away. At the All of Us chr22 grid only 0.45% of (region, sample, ploid) windows hold a variant, the dense intermediate is ~128 GB per contig, and the np.nonzero scan that recovered the useful cells was 71% of the per-chunk write kernel.

genoray now emits exactly those cells (d-laub/genoray#206), so the writer consumes SparseVar2._find_ranges_chunked_sparse. The scan and the intermediate both disappear; nonempty_entries collapses into a CSR expansion plus four column assignments and is deleted.

The output does not change

Byte for byte. The two paths already agreed on every convention:

convention	old nonempty_entries	genoray sparse
filter predicate	end > start per channel, OR'd	same
cell_id	slot * ploidy + ploid, selection-absolute	same
empty channel	raw start, len = 0 (not zeroed)	same
order	region-major, cell_id ascending	same

test_write_svar2_chunked_matches_unchunked compares the on-disk table across chunk boundaries and still passes, with its spy now confirming the sparse stream is the one being driven.

Also in here: the fixtures move to genoray's grouped pipeline args

The same version bump carries genoray's #153/#200 refactor, which made the _core pipeline entry points keyword-only with RegionSpec / FieldSpec / PlanSettings. GVL called them positionally at 12 sites across 9 test files, so all 12 are ported.

One guard intentionally removed

nonempty_entries's shape check defended against a mis-transpose. There is no transpose left — the chunk arrives region-major — so that axis order is now unrepresentable rather than validated. Its int32 cell-id overflow guard is already enforced by _SparseWriter's span >= 2**31 check.

Pinned to genoray 5.0.0

The release landed as 5.0.0, not the 4.1.0 this branch first anticipated, so the original >=4.1.0,<5 pin excluded the very release it was waiting for. Now pinned >=5,<6 in pyproject.toml and pixi.toml, relocked, and both Cargo.toml git deps (svar2-codec, genoray_core) moved to the 5.0.0 tag commit 714f876.

5.0.0's breaking changes — the GENORAY_* environment variables, the reader_workers= parameter, and resolve_log_level — all land on APIs genvarloader never calls, so none of them required a change here.

Re-checked the empty-cell contract at the new rev, as the Cargo.toml comment asks: gather_haps_readbound_impl (genoray:src/query/gather.rs:869 at 5.0.0) still consumes every range purely as a slice bound (d_snp_pos[ss..se], snp_positions[vs..ve]), so a len == 0 range yields an empty slice and its start is never dereferenced.

Testing

Against the real genoray 5.0.0 wheel, full suite (after pixi run gen):

1315 passed, 43 skipped, 4 xfailed, 0 failed — pytest tests -p no:randomly --ignore=tests/benchmarks, 3m06s.

cargo check --all-targets is clean at the new rev, and all prek hooks (ruff check/format, pyrefly, pixi lock, commitizen) pass.

Unblocks d-laub/genoray#204 (deleting genoray's dense chunk path).

🤖 Generated with Claude Code