docs: conformance report with the last non-ok files classified (602 of 697 ok, 0 our-error, 0 mismatch)

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

CHANGELOG.md

@@ -2,6 +2,27 @@
 
 ## Unreleased
 
+### Conformance: no our-errors or mismatches left (2026-09-27)
+- The last 3 our-errors and 2 mismatches were documented as not ours but
+  still counted against us. Re-checked with evidence
+  (`docs/known-issues.md`, "Conformance: the last non-ok files"):
+  - The 2 mismatches were h5py's big-endian VL bug (elements returned with
+    the file's bytes under a little-endian dtype). `conformance/ref.py` now
+    checks the installed h5py has the bug and relabels such elements before
+    hashing, so their values are compared: `attr_datatypes.hdf5` and
+    `tcomplex_be.h5` are identical to clawhdf5's and now **ok**.
+  - The 3 our-errors are objects HDF5 2.0 reads by over-reading memory
+    (scale-offset codes past a chunk, unfiltered chunks shorter than a
+    chunk, an N-Bit parameter list one value short). h5py's values for them
+    change between runs, with `MALLOC_PERTURB_` and with import order, and
+    h5dump 1.14.6 prints others, so they are not the file's data and
+    clawhdf5 keeps refusing them. `conformance/ref_bugs.py` repeats that
+    check in every run, and such a file is the new class **ref-bug** only
+    while its values keep changing.
+- Result (`conformance/run.sh --no-fetch`, tank, 2026-09-27): 602 of 697
+  ok (baseline 600), 0 our-error, 0 mismatch, 3 ref-bug, 92
+  h5py-cannot-read, no panic/hang/crash/oom.
+
 ### Deterministic errors on damaged chunked datasets (2026-09-27)
 - A read through the file's chunk cache listed a damaged dataset's chunks in
   hash-map order, seeded per `File`, so two opens of the same file could