facade: open_swmr reads live only files with the SWMR-write flag

A file opened with open_swmr whose superblock does not have the SWMR-write
flag (its writer has closed it) is now read exactly as File::open reads it:
bounded by its recorded end of file, through the chunk cache, each
operation tried once, and is_swmr_read() is false. Before, every file opened
with open_swmr ignored its recorded end of file, so a closed file whose end
of file is below its length (h5clear_fsm_persist_less.h5, or the mid-write
fixture with its flags cleared) listed and read objects that File::open and
libhdf5's plain reader refuse. Opening such a file is not retried once the
superblock has been read.

libhdf5's SWMR reader is looser than either (it reads the fixture's chunk
index past the end of file even with the flags cleared); a test pins what
h5py does and docs/design/swmr.md says why we follow the plain reader.

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

docs/design/swmr.md

@@ -76,6 +76,18 @@ writer keeps appending. What the format and the library guarantee:
      chunks it needs again. A cached index would hide new chunks, and a
      cached partial edge chunk would read as fill where the writer has since
      written data (unfiltered edge chunks are rewritten in place).
+   - Only a file whose superblock has the SWMR-write flag when it is opened
+     is read live. Any other file is read exactly as `File::open` reads it
+     (bounded by its recorded EOF, through the chunk cache, no retries), and
+     `is_swmr_read()` is `false`. libhdf5's SWMR reader is looser: it skips
+     the end-of-allocation check in `H5FD_read` for every file it opens,
+     flagged or not, yet still refuses an object header past the EOF
+     (`H5O_protect`, "address of object past end of allocation"). On a
+     closed file whose EOF is below its length (checked 2026-09-27, h5py
+     3.16 / HDF5 2.0, the mid-write fixture with its flags cleared) it
+     therefore reads a dataset whose chunk index lies past the EOF, which
+     its plain reader refuses. We follow the plain reader there: the EOF of
+     a file no SWMR writer has open is what the file says it is.
    - A storage that caches blocks (`clawhdf5-remote`'s `BlockCache`) would
      serve stale bytes; `HttpStorage` also pins a file by ETag and length and
      refuses a changed file. Remote SWMR is out of scope.