clawhdf5-remote: ObjectStoreStorage works from any thread

It refused whenever Handle::try_current() was Ok, which is also the case
inside spawn_blocking threads — so the workaround its own error message
recommended failed the same way, and the backend could only be used from
a bare std::thread in a tokio application.

Reads are now spawned on the storage's own runtime and the caller waits on
a channel: the future never runs on the caller's thread, so neither a
spawn_blocking thread nor a current-thread runtime can deadlock or panic
(a read inside a runtime blocks that thread, like any blocking call; the
docs still recommend spawn_blocking there).

Tests: a read in spawn_blocking of a multi-thread runtime and a read inside
a current-thread runtime's task give File::open's values (both errors
before).

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

CHANGELOG.md

@@ -32,9 +32,10 @@
     backoff; bodies are asked for with `Accept-Encoding: identity` and an
     encoded one is refused. The ranges of one call are fetched in parallel.
   - **`ObjectStoreStorage`** reads one object of any `object_store` store,
-    pinned by ETag (else version or modification time) and size. It blocks
-    on a small tokio runtime it owns; called from inside another runtime it
-    refuses (`RemoteError::Usage`) instead of blocking a worker.
+    pinned by ETag (else version or modification time) and size. Each read
+    runs on a small tokio runtime the storage owns while the caller waits,
+    so it works from any thread, `spawn_blocking` and other runtimes
+    included.
     `open_object(store, path, options)` opens a file through a block cache.
   - Counted on the conformance corpus (tank, 2026-09-26,
     `CLAWHDF5_REMOTE_CORPUS=conformance/.cache/corpus CLAWHDF5_REMOTE_REPORT=1