fix(tools,wasm): resolve VL data through the library's VlResolver

h5rs (dump, ls, diff, check --data) kept its own lenient VL decoder:
a heap object longer than its element was cut to the element's length
(libhdf5 and h5py refuse it), a null string printed "" where h5dump
prints NULL, the stored element size was trusted, and every heap
collection was kept as an owned copy for the whole run. It now resolves
each element with VlResolver::element / string_element (new: one element
in place, borrowing from the file), and refuses a VL type whose stored
element size is not 4 + offset size + 4, as File does. H5::heap_object
and its cache are gone. h5diff compares a null VL string equal to an
empty one; so does h5rs diff.

clawhdf5-wasm already resolved VL strings with read_vl_strings; it now
uses VlResolver and checks the stored element size before reading, as
File::read_string does.

Tests (h5py writes the files, patched for "a\0b", a null element and
mis-sized heap objects, with 8- and 4-byte offsets):
- h5rs_interop dump_prints_vl_data_like_h5dump: byte-identical to h5dump;
- dump_json_vl_values_match_h5py: h5py's values, errors where h5py fails;
- check_data_flags_mis_sized_vl_heap_objects;
- clawhdf5-wasm tests/vl_strings.rs: wasm, File and h5py agree.
All four fail before. check --data over the 150 cve_hdf5 CVE and fuzzer
files now passes 15 (h5dump rejects 8 of them), was 16 and 9: the
stored-size check flags cve-2024-32608. h5rs-check-ok-files.sh --data:
0 of 422 flagged; h5rs-fuzz.sh: clean on 180 files.

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

docs/known-issues.md

@@ -207,9 +207,10 @@ fill-value item that did is fixed).
   - (`cve-2024-32616` `/group1/dset3` and `cve-2025-2309`'s `Comp_OBJREF`
     attribute are h5py/numpy type-mapping failures, not libhdf5 refusals.)
   - `h5rs check` validates with the library's parsers, so it inherits what
-    they accept: of the 150 CVE and fuzzer files, `check --data` passes 16,
-    and h5dump 1.14.6 rejects 9 of those (tank, 2026-09-26; 28 and 21
-    before these checks).
+    they accept: of the 150 CVE and fuzzer files, `check --data` passes 15,
+    and h5dump 1.14.6 rejects 8 of those (tank, 2026-09-26; 28 and 21
+    before these checks, 16 and 9 before a VL type's stored element size
+    was checked, which flags `cve-2024-32608`).
 - **Writer:**
   - Nested groups beyond one level: path-like names are now refused, not
     created.
@@ -537,8 +538,9 @@ which is what libhdf5 itself writes.
   followed (no file system).
 - Variable-length string datasets are read by decoding `read_selection`'s
   bytes with `clawhdf5_format::vl_data` in the wasm crate; `File` itself still
-  cannot (see the audit gaps above). (`File` can since 2026-09-26; the wasm
-  crate still decodes them itself.)
+  cannot (see the audit gaps above). (`File` can since 2026-09-26. Since
+  2026-09-26 the wasm crate resolves them with the same `VlResolver` as
+  `File` and `h5rs`, so all three return h5py's values.)
 
 ## The Node.js package (`packages/clawhdf5-node`) does not work