py: remote files (clawhdf5.File(url), File.open_url) through File::storage()

The Python bindings could not open a remote file: they parsed through
File::as_bytes() in eight places (path lookups, object headers,
dataspaces, attributes, group listings, the global heap of
variable-length data), which a storage-backed file does not have.

- Every object of a File now shares one handle (src/handle.rs) that
  runs all file access, metadata included, with the GIL released and
  parses through File::storage() and the clawhdf5_format *_in functions.
  Local files take the same path (their storage is the mmap).
- clawhdf5.File(url) opens any scheme://... through
  clawhdf5_remote::storage_for_url (read-only; another mode is a
  ValueError). File.open_url(url, **options) takes the cache and HTTP
  options (block_size, cache_size, headers, retries, timeout,
  allow_full_download, max_full_download, require_validator,
  max_redirects, max_parallel); File.remote_stats gives the block
  cache's counters.
- Default build: plain HTTP only, no C. https (rustls/ring) and
  s3/gcs/azure (aws-lc-rs) are opt-in features of clawhdf5-py, and
  ci-test.sh's no-C check now covers the crate.
- A failed storage read (network error, file changed on the server) is an
  OSError, never KeyError/ValueError and never data; `key in group`
  raises it instead of answering False.

Tests: the read-vs-h5py suite runs locally and over HTTP (1 MiB and
1 KiB blocks) against a range-capable http.server in the test process
(conftest.RangeServer); test_remote.py covers request counts, cache
hits, a server without Range support, a changed file, a server that
hangs up, 16 threads, and a spinning thread that keeps running while a
read waits on 0.2 s requests.

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

scripts/ci-test.sh

@@ -131,14 +131,17 @@ run_step "cargo clippy (h5rs remote)" cargo clippy \
 # js-sys (clawhdf5-wasm's bindings to JavaScript) builds no C.
 # clawhdf5-remote is checked by default (plain HTTP) and with its
 # object-store feature, and h5rs with URL support (remote); the https
-# (ring) and s3/gcs/azure (aws-lc-rs) features build C and are opt-in.
+# (ring) and s3/gcs/azure (aws-lc-rs) features build C and are opt-in. The
+# Python bindings (clawhdf5-py, remote reads over plain HTTP) are checked too:
+# their https/s3/gcs/azure features are opt-in for the same reason.
 no_c_in_default_build() {
     local entry crate features found=0
     for entry in clawhdf5-format clawhdf5-io clawhdf5-filters clawhdf5 \
         clawhdf5-agent clawhdf5-ann clawhdf5-accel clawhdf5-netcdf4 clawhdf5-cli \
         clawhdf5-tools \
         clawhdf5-wasm \
-        clawhdf5-remote clawhdf5-remote:object-store clawhdf5-tools:remote; do
+        clawhdf5-remote clawhdf5-remote:object-store clawhdf5-tools:remote \
+        clawhdf5-py; do
         crate=${entry%%:*}
         features=()
         [ "$entry" != "$crate" ] && features=(--features "${entry#*:}")