fix(format): apply the base address of files with a user block

A file may start with a user block (h5py userblock_size, h5jam), putting
the superblock at 512, 1024, ...; every address in the file is then
relative to the superblock. The signature search found it, but every
reader passed the whole file to the parsers, so addresses landed
userblock bytes early and the root group failed with
InvalidObjectHeaderVersion (twithub.h5, twithub513.h5,
h5clear_fsm_persist_user_*.h5).

Readers now view the file from the superblock on, taking the signature's
position as the base address as libhdf5 does: File (mmap, buffered,
from_bytes), MmapFile, LazyFile, AsyncHDF5File, the VOL and MPI VOL
readers, the HNSW loader and external VDS source files. File, MmapFile
and LazyFile gain user_block_size(). The new signature::split_user_block
returns the two parts, and Superblock::parse refuses a non-zero offset
(UserBlockNotStripped) so a format-level caller cannot silently apply
superblock-relative addresses to the whole file.

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

docs/known-issues.md

@@ -73,6 +73,9 @@ the VDS item, which is marked.
   - `%b` printf-style source names are not expanded.
   - Hyperslab selection versions 1 and 2 are refused.
 - **Files with a user block:** the base address is not applied.
+  **Fixed 2026-09-25:** every reader views the file from the superblock on
+  (`twithub.h5`, `twithub513.h5`, `h5clear_fsm_persist_user_*.h5`; the
+  `twithub` files still stop at the user-defined link type below).
 - **Old-style shared messages (version 1)** read the wrong address.
   **Fixed 2026-09-25:** the address follows a length-sized heap offset
   (`tcompound.h5`, `tcompound2.h5`; their datasets now stop at the layout