fix: pin hdf5-metno-src to 0.10.2 so the tree builds again

[rob-p]

Fixes #38.

A clean checkout of main currently fails to build anndata-hdf5:

$ cargo check -p anndata-hdf5
error: failed to run custom build command for `hdf5-metno-sys v0.11.3`
  thread 'main' panicked at hdf5-metno-sys-0.11.3/build.rs:222:21:
  Invalid H5_VERSION: "2.2.0"

Nothing in this repo changed. hdf5-metno-src 0.10.3 (published 2026-08-04) bumped the bundled HDF5 to 2.2.0. hdf5-metno-sys 0.11.x depends on it as ^0.10, so it is picked up automatically — but 0.11.x's build script accepts only HDF5 minor versions {0,1,8,10,12,14}. The parser fix shipped in hdf5-metno-sys 0.12.2 only; reported upstream as metno/hdf5-rust#202.

Moving to -sys 0.12.x is not currently reachable from here. This crate requires both hdf5-metno-sys ^0.11 and hdf5-metno ^0.12.3, and any hdf5-metno >= 0.12.6 requires hdf5-metno-sys ^0.12. Because hdf5-metno-sys declares links = "hdf5", cargo refuses to have two copies rather than picking one:

package `hdf5-metno-sys` links to the native library `hdf5`, but it conflicts
with a previous package which links to `hdf5` as well

So this pin is the minimal fix that restores the build.

Declaring hdf5-metno-src directly costs nothing: this crate already enables hdf5-metno-sys's static feature unconditionally, so those sources are compiled in every configuration anyway. The pin only selects which of them.

Verified

cargo check -p anndata-hdf5        # ok
cargo test -p anndata -p anndata-hdf5 -p anndata-zarr
                                   # 19 passed; 0 failed

rustc 1.97.1, x86_64-unknown-linux-gnu, cmake 3.29.2.

When this can be reverted

Once either metno/hdf5-rust#202 is resolved (e.g. the 2.x version regex backported to a -sys 0.11.4, or the HDF5-2.2.0 sources republished as -src 0.11.0), or this crate moves both requirements to hdf5-metno 0.14 + hdf5-metno-sys 0.12.1. Note that the latter currently trips metno/hdf5-rust#203 on RHEL-family hosts, where HDF5 2.x installs to lib64 but hdf5-sys links against lib.