feat(svar2)!: plan conversion concurrency under core and memory budgets (+ scale-bench harness)

.gitignore

@@ -30,3 +30,7 @@ memray_flamegraphs/
 
 # dhat heap profiles emitted by `--features dhat-heap` benches into CWD
 dhat-heap.json
+
+# Slurm logs from scripts/bench_svar2/*.sbatch (#SBATCH --output=%x_%j.log
+# resolves against the submission directory, which is the repo root).
+svar2-*.log

docs/roadmap/svar-2.md

@@ -401,9 +401,11 @@ Legend: `[ ]` not started · `[~]` in progress · `[x]` done
   so Approach B was not built. Public API is unchanged — sharding is entirely
   internal to the existing `threads=` budget. Byte-identical output vs. serial
   conversion is gated by a store-hash oracle at every thread count for both
-  backends. **VCF** scales ~3.9× at 32 cores (chr21, 1176s → 300s); sub-contig
-  sharding only engages once the thread budget clears HTSlib decode-thread
-  allocation (~15 cores). **PGEN** sharding is byte-identical but not faster —
+  backends. **VCF** scales ~3.9× at 32 cores (chr21, 1176s → 300s). Its
+  backend-specific `reader_workers` budget treats indexed shard readers as a
+  replacement for the monolithic reader's HTSlib pool and disables per-shard
+  HTSlib background pools, so medium-sized single-contig runs no longer strand
+  cores in an inactive reservation. **PGEN** sharding is byte-identical but not faster —
   `pgenlib`'s genotype decode holds the CPython GIL, so shard readers serialize
   and sharding is net slightly slower than serial (memory
   `pgenlib-holds-gil-sharded-reads`); PGEN is intentionally not over-decomposed.

docs/source/svar.md

@@ -73,13 +73,14 @@ regions per contig raise — use `pos`/`record`, or convert separately.
 
 Single-file `SparseVar2.from_vcf` shards **within a contig**, driven by the same
 `threads=` budget shown above — no new argument. Sub-contig sharding only kicks
-in for the default whole-contig (`regions_overlap="pos"`) path: the thread budget
-first spends added cores on HTSlib decode threads for the single reader, so the
-sub-contig shard budget stays at 1 (an un-sharded reader) until the core count
-clears that stage (~15 cores on the benchmarked hardware). Output is
-**byte-identical** to serial conversion at every thread count — sharding is gated
-by a store-hash oracle and does not reintroduce missingness (a `./.` haplotype
-and a hom-ref haplotype remain indistinguishable in SVAR2 either way).
+in for the default whole-contig (`regions_overlap="pos"`) path. The planner uses
+a backend-specific reader budget: indexed shard readers decompress inline and
+replace, rather than run alongside, the monolithic reader's HTSlib pool. This
+lets medium-sized single-contig runs use their available cores without
+oversubscribing multi-contig runs. Output is **byte-identical** to serial
+conversion at every thread count — sharding is gated by a store-hash oracle and
+does not reintroduce missingness (a `./.` haplotype and a hom-ref haplotype
+remain indistinguishable in SVAR2 either way).
 
 Sub-contig sharding is restricted to `regions_overlap="pos"` (which the
 whole-contig default uses). `"record"` and `"variant"` conversions run on a