fix: open a file whose cache image cannot load, and fail its objects

For a metadata cache image libhdf5 cannot load, libhdf5 opens the file
and fails the first metadata read (the image loads on the first
H5C_protect after open); h5py reports the error on the root group. The
conformance probe reported it that way, but File::open refused the file,
so the gate counted cve-2025-6269-1..4 and cve-2025-6516 as agreeing
with h5py for behaviour the library did not have.

The library now behaves as the probe reports: File (mmap, buffered and
from_bytes) and MmapFile open the file and every object lookup (dataset,
dataset_at, group, group listings and attributes, VL decoding) fails with
the image's error; LazyFile reads the root group's header at open, so
its open is that first read and fails. Probe and library take the
three-way decision (refuse at open / image loads / image cannot load)
from the same clawhdf5_format::superblock_ext::cache_image_state.

One deliberate difference from libhdf5 remains, documented: after the
failed first read libhdf5 reads the file's own metadata, which the image
was meant to replace and may be stale; here every lookup keeps failing.
File::cache_image_error / MmapFile::cache_image_error expose the error
to code that parses as_bytes() itself; h5rs checks it before reading any
object header (h5rs ls on cve-2025-6269-1 said "invalid object header
version: 0" from the stale bytes).

Test: metadata_cache_image.rs an_image_libhdf5_cannot_load_fails_every_object
(the fixture with its image signature broken; h5py opens that file and
fails the first read with "Bad metadata cache image header signature").
It fails on the previous commit, where File::open refuses the file.

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

docs/known-issues.md

@@ -205,9 +205,19 @@ fill-value item that did is fixed).
   - Metadata cache images are not supported. **Fixed 2026-09-26:** the
     image is applied at open, as libhdf5 loads it over the file's metadata
     (`clawhdf5_format::superblock_ext`); `h5clear_mdc_image.h5` reads
-    (`crates/clawhdf5/tests/metadata_cache_image.rs`). A file whose image
-    libhdf5 cannot load (`cve-2025-6269-*`, `cve-2025-6516`) opens in
-    libhdf5 with nothing readable in it; `File::open` refuses it.
+    (`crates/clawhdf5/tests/metadata_cache_image.rs`), without copying the
+    file (a private copy-on-write mapping takes the image's entries;
+    `tests/cache_image_memory.rs`). A file whose image libhdf5 cannot load
+    (`cve-2025-6269-*`, `cve-2025-6516`) opens, as in libhdf5, and every
+    object lookup fails with the image's error. Differences from libhdf5
+    that remain: libhdf5 fails only the first metadata read and then reads
+    the file's own (possibly stale) metadata, where we keep failing; an
+    image entry that runs past the end of file is refused (libhdf5 checks
+    only its start); a flush-dependency parent flag is checked against the
+    child count as libhdf5's debug build checks it (HDF5 2.0 release
+    builds refuse every entry that has children, even in images they
+    wrote); the superblock extension's driver-info and shared-message table
+    messages are not decoded at open.
   - x87 long double and binary128 are refused.
   - N-Bit on 64-bit scale-offset data and some N-Bit parameter layouts fail.
     **Not our bug (checked 2026-09-26):** both are corrupt files HDF5 2.0