Measure the borrow, rather than asserting it bounds the disk

The claim that hydration-as-a-borrow makes peak disk the working set
rather than the library was so far an argument. `--example vfs_cycle`
runs it: 100 photographs of 25 MB, 90 dehydrated, a pass over all of
them through the real engine.

Peak 275 MB — the resting set plus one photograph — against 2,500 MB
had the pass simply fetched everything. Back to 250 MB afterwards, and
all ten files the user already kept still there, which is the half of
the contract that matters more.

Recorded in docs/storage.md §6.3 and ARCH §9.0a, because a bound argued
from a number nobody measured is one that gets quietly lost.

docs/storage.md

@@ -465,6 +465,21 @@ A borrow against a plain folder or a server backend short-circuits and does
 nothing, so a pass written for a VFS library runs unchanged everywhere rather
 than growing two code paths.
 
+**Measured 2026-08-29**, `cargo run -p dr-sync-folder --example vfs_cycle`: a
+library of 100 photographs at 25 MB each, 90 of them dehydrated and 10 the user
+keeps. A pass over all 100, borrowing and releasing as it goes:
+
+| | |
+|---|---|
+| on disk at rest | 250 MB |
+| **peak during the pass** | **275 MB** — the resting set plus one photograph |
+| without borrowing | 2,500 MB |
+| on disk afterwards | 250 MB |
+| of the 10 the user already had | 10 still there |
+
+The peak is the working set, not the library, and the release is selective.
+
+
 ### 6.4 Release means dehydrate, never delete
 
 The single most dangerous thing in this feature. A synced folder is not a