fix(format): read VL values in files with 4-byte offsets

In a file with sizeof_addr = 4, a VL string attribute came back as
AttrValue::Raw, a compound's VL member failed with
GlobalHeapObjectNotFound and VL datasets failed with a size mismatch.

Two bugs: Datatype::type_size() said 16 for every VL type, while the
element is 4 + offset size + 4 bytes (12 here); and the global heap was
parsed without the padding libhdf5 puts after its collection and object
headers (both round up to 8), so with 4-byte lengths every object was
looked up 4 bytes early. Datatype::VariableLength now carries the size
its datatype message stores, and writes it back.

Checked against h5py in tests/vl_offset4_interop.rs (fails with either
fix reverted). Conformance unchanged at 575 of 697; in cve-2024-32608 a
VL attribute whose datatype claims 524304-byte elements is now an error
(h5py cannot iterate those attributes at all).

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

docs/known-issues.md

@@ -146,7 +146,10 @@ fill-value item that did is fixed).
     `GlobalHeapObjectNotFound` or come back as `Raw`: these paths assume
     the 16-byte element of an 8-byte-offset file. The datatype itself reads
     (it was refused as "member overlaps with previous member" until
-    2026-09-26).
+    2026-09-26). **Fixed 2026-09-26:** a VL type's element size is the one
+    its datatype message stores (12 with 4-byte offsets), and the global
+    heap is read with libhdf5's header padding
+    (`crates/clawhdf5/tests/vl_offset4_interop.rs`).
   - Metadata cache images are not supported.
   - x87 long double and binary128 are refused.
   - N-Bit on 64-bit scale-offset data and some N-Bit parameter layouts fail.