Measure the folder walk against a real tree, not a claim

The folder connector declares `LocalEtags`, which means the engine walks
the whole library on every scan with no pruning. That is the honest
capability, and the argument for it being affordable was so far an
assertion about `stat` versus `PROPFIND`.

`--example scan` runs the real path — `dr_sync::scan` over the connector,
then a ranged read of the kind the thumbnail worker makes. Read-only; it
never writes into the folder it is pointed at.

2,299 images across 233 directories in 137 ms, and 380 across 13 in
29 ms. Against 34.1 s for 17,185 RAWs over WebDAV *with* pruning
available. Recorded in docs/storage.md §5.2 and ARCH §8.4a, because a
capability trade-off argued from a number nobody measured is the kind
that gets quietly reversed later.

docs/architecture.md

@@ -794,9 +794,11 @@ Three things worth carrying forward:
 
 - **`LocalEtags` is the honest answer, and it costs nothing.** A POSIX directory's mtime describes
   its own entry list and nothing below it, so there is no propagation to exploit and the engine
-  walks the tree every scan. The walk that was expensive was expensive because it was 50k
-  `PROPFIND`s; 50k `stat` calls take well under a second. This is the capability model paying for
-  itself — one engine, two backends, each running at the speed it actually runs at.
+  walks the tree every scan. **Measured 2026-08-28**: a full uncached walk of 2,299 images
+  across 233 directories took **137 ms**, with no pruning at all — against 34.1 s for 17,185 RAWs
+  over WebDAV *with* pruning (§8.4). The walk that was expensive was expensive because it was
+  thousands of `PROPFIND`s. This is the capability model paying for itself — one engine, two
+  backends, each running at the speed it actually runs at.
 - **Identity is a path hash, not an inode.** An inode is stable across a rename but differs between
   devices and is reused after a delete, so two machines would disagree about which photograph a
   thumbnail belonged to and a recycled inode would attach an old thumbnail to a new image.