fix(format): resolve cache-image flush-dependency parents as libhdf5 does

The review suggested libhdf5 loads every image entry and resolves
flush-dependency parents afterwards. It does not:
H5C__reconstruct_cache_contents (HDF5 1.14.6 and 2.0.0, and develop)
inserts each entry and then searches the cache index for its parents in
the same loop, failing with "fd parent not in cache?!?" when one is
missing. So a parent must be an earlier image entry, as before, or
metadata cached before the image loads: the superblock (address 0) and
the superblock extension's object header, which libhdf5 reads to find
the image. Those two were refused as parents; they are now accepted.
A parent listed after its child is still refused, as libhdf5 refuses
it, and so is an entry that is its own parent ("Child entry flush
dependency parent can't be itself").

apply_cache_image takes the superblock to know the extension address.

Test: superblock_ext::tests::flush_dependency_parents_must_already_be_cached
(parent-first loads, child-first refused, extension header accepted,
self-parent refused); the extension-header case fails without the fix.

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

conformance/probe/src/main.rs

@@ -731,7 +731,7 @@ fn main() {
     let view = match ext.and_then(|x| x.cache_image) {
         None => None,
         Some(loc) => match guarded(|| {
-            superblock_ext::apply_cache_image(hdf5, loc, sb.offset_size, sb.length_size)
+            superblock_ext::apply_cache_image(hdf5, loc, &sb)
                 .map_err(e)
         }) {
             Ok(v) => Some(v),