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]>

docs/design/range-reads.md

@@ -471,9 +471,10 @@ fast path within benchmark noise.
     with ring. S3/GCS/Azure go through `object_store` (`ObjectStoreStorage`,
     features `s3`/`gcs`/`azure`, opt-in because of aws-lc-rs); the
     `object-store` feature alone (in-memory, local files, a store you
-    build) is pure Rust. object_store is async: the storage blocks on a
-    two-thread tokio runtime of its own, and refuses to run inside another
-    runtime.
+    build) is pure Rust. object_store is async: each read runs on a
+    two-thread tokio runtime of the storage's own while the caller waits,
+    so the caller's context (a plain thread, `spawn_blocking`, another
+    runtime) does not matter.
   - `BlockCache` (any `Storage`): 1 MiB blocks and a 64 MiB LRU budget by
     default, the first block fetched at open (for HTTP by the request
     that learns the length), the missing blocks of one read fetched as