docs: fewer round trips for remote files in the browser, counted

CHANGELOG (Unreleased): the v1 B-tree lookup, `Storage::hint`, the walks
that go on past a missing node, and the counts before and after on an
h5py file like the reviewer's (3000 datasets, 198 MB, earliest and
latest libver, 1 MiB and 64 KiB blocks), the corpus read lazily at
512 B and 64 KiB blocks, and the Node/Chromium suite.
known-issues (browser limits, round trips): the new counts, why the
passes cannot go lower (the chain of addresses), why merging nearby
requests does not help such a file, and that a second listing refetches
at 1 MiB blocks when the file's metadata blocks exceed `cacheSize`.
range-reads.md M4 status and the viewer README follow.

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

docs/design/range-reads.md

@@ -607,6 +607,16 @@ fast path within benchmark noise.
     missing blocks: listing 3000 datasets went from 185 passes to 6.
     The 32-bit risk below is covered by a Node test that reads data at
     3 GiB from a mock server and is refused a 4 GiB file.
+  - Fewer round trips (2026-09-27, later): the walks descend into every
+    child after a failure (not only read the siblings), and parsers
+    call `Storage::hint` for what they read next (node bodies, object
+    header chunks, a dense group's heap blocks, a listing's child
+    headers); `LazyStorage` fetches hinted blocks only along with a
+    pass's real misses and within `maxFetch`, so hints never add a
+    round trip nor change a result. A v1 group's name is looked up down
+    its B-tree (`H5G__stab_lookup`), not by listing it. 3000 datasets
+    list in 4 passes (earliest) and 5 (latest) at 1 MiB blocks, and
+    opening one of them costs 5 requests, not 74 (CHANGELOG).
 
 **M5 — SWMR and growth (later, separate design).** `Storage::len()` may grow;
 add `File::refresh()` that re-reads the superblock/EOF and invalidates cached