fix(read): decode on the calling thread when rayon's pool has one thread

Full reads of chunked datasets handed their chunks to rayon. With a
one-thread pool (concurrent_read --decode-threads 1, RAYON_NUM_THREADS=1)
every thread reading through a File queued behind that single worker, so
16 readers decoded on one core: per-thread CPU time showed one thread
doing all the decoding and the readers almost none, and full reads
stopped at about 2x one thread. The cached full-read path and the
uncached reader behind verify_provenance now decode inline when the pool
cannot parallelise (parallel_read::pool_can_parallelise).

The File's chunk cache was the suspect but not the cause: datasets over
its budget were already read without inserting, and skipping its lookups
gained only a few percent at 16 threads.

The regression test keeps a one-thread global pool's worker busy and
requires a full read and verify_provenance to finish anyway; before the
fix both waited for the worker (timed out).

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

BENCHMARKS.md

@@ -528,7 +528,11 @@ What this shows:
     (about 880 MB/s) while h5py processes reach 4424 MB/s. Hyperslab
     reads, which bypass the `File`'s chunk cache, keep scaling, so the
     cache (one mutex and one 16 MiB budget per `File`, thrashed by 64 MiB
-    datasets) is the suspect.
+    datasets) is the suspect. **Fixed after these measurements
+    (2026-09-26); the table above predates the fix and has not been
+    re-measured.** The cause was not the cache: with `--decode-threads 1`
+    every full read queued its chunks for the pool's single rayon worker;
+    see `docs/known-issues.md`.
   - *Contiguous reads are slow*: 2.5 GB/s for a single-threaded full read
     against h5py's 9.8 GB/s (0.25x), and 0.12x for 256 x 256 hyperslabs.
     Threads close the gap (about 1.0x h5py at 16), but single-thread