feat(format): decode hyperslab selection versions 1 and 2 in VDS mappings

libhdf5 serializes a VDS hyperslab as version 1 (irregular, 4-byte block
corners) for the default format bounds, and as version 2 (regular, 8-byte)
for unlimited selections in the 1.10 format. Only version 3 was accepted,
so every h5py VDS written with default libver failed with "only version-3
hyperslab selections are supported" (5 libhdf5 test files in the sweep).

Decode all three versions following H5S__hyper_deserialize, including
irregular hyperslabs (a union of blocks, enumerated in row-major order as
libhdf5 iterates them) and the all-ones "unlimited" count/block marker.
SerializedSelection exposes the raw form for unlimited-mapping support.

Test: vds_interop::vds_version1_irregular_hyperslab_selections compares
default-libver h5py VDS reads (contiguous, strided and 2-D block mappings)
with libhdf5's values.

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

CHANGELOG.md

@@ -273,6 +273,15 @@
 - CI keeps zlib-ng building and tested; the arm64 job no longer needs cmake.
 
 ### Correctness
+- `clawhdf5-format` virtual datasets (VDS), checked against HDF5 2.0 through
+  h5py (`crates/clawhdf5/tests/vds_interop.rs`):
+  - Hyperslab selection versions 1 and 2 were refused ("only version-3
+    hyperslab selections are supported"). Version 1 is what libhdf5 writes for
+    every VDS created with the default format bounds (h5py's default), so
+    those could not be read at all; version 2 is its encoding of an unlimited
+    selection. Both are decoded now, as are irregular hyperslabs (a union of
+    blocks, read in row-major order as libhdf5 iterates them).
+    `SerializedSelection` exposes the raw form, including unlimited counts.
 - `clawhdf5-format` reader — **values returned wrong with no error:**
   - Fixed Array and Extensible Array chunk indexes were laid out by the
     dataset's current shape instead of its max shape (23 libhdf5 test files,