fix(format): a VL element at the undefined heap address is an error

libhdf5 fails to read a VL element whose global heap address is
undefined (all 0xff), even at length 0 ("addr undefined"); we returned
"" (or an empty sequence) in every reader. Checked with h5py first:
libhdf5 writes a null element with address 0, which still reads as
empty, and h5py writes "" as a zero-size heap object at a real address,
so no file they write relies on the old behaviour. read_vl_bytes now
treats address 0 as null whatever the length, as VlResolver does.

Tests, each failing before: vl_data unit test (8- and 4-byte offsets,
lengths 0 and 1); clawhdf5 vl_data_interop
a_vl_element_at_the_undefined_heap_address_fails_like_h5py (also checks
where h5py writes ""); h5rs dump --json and check --data on the patched
`undef` dataset; clawhdf5-wasm vl_strings.

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

docs/known-issues.md

@@ -143,7 +143,9 @@ fill-value item that did is fixed).
   - VL-string datasets are not readable through `File`. **Fixed
     2026-09-26:** `read_string` reads them (also `read_string_bytes`,
     `read_string_selection`, and on `MmapFile`/`LazyFile`), with h5py's
-    values: strings end at a NUL, null elements are `""`; VL sequences of
+    values: strings end at a NUL, null elements (heap address 0) are `""`,
+    and an element at the undefined heap address is an error as in libhdf5
+    (it read as `""` until 2026-09-26); VL sequences of
     numbers read with `read_vlen::<T>()`, and VL values inside compounds or
     `AttrValue::Raw` attributes decode with `File::decode_strings` /
     `File::decode_vlen` (`crates/clawhdf5/tests/vl_data_interop.rs`).