docs: record which download paths have actually been run

The download-to-disk story is three mechanisms — File System Access in
Chrome, a service worker streaming a response in Firefox and Safari, a
blob as the floor — and no test in this repository exercises any of them.
test_downloads.py pins their contracts by reading the source; whether a
browser really writes to disk needs a person with a large file.

One now has: Firefox, 180 MB, written to disk rather than assembled in
the tab. That is the path worth confirming, since it is the only one
Firefox has and it was written blind. It is also not the scale it exists
for, and the guide says which rows of that table are measured and which
are still only designed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1 files changed, 8 insertions, 0 deletions

diff --git a/CLAUDE.md b/CLAUDE.md
index ad215d5..6701d7d 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -254,6 +254,14 @@ keypair bundle, or anything that looks like a user's public key.
   `deploy-hub.sh` runs `alembic upgrade head` before restarting the service; a schema
   change that skips a migration file will still pass every test you have
 
+- **Some paths only exist in a browser, and only one browser has them.** The
+  download-to-disk story is three different mechanisms — File System Access
+  (Chrome/Edge), a service worker streaming a response (Firefox/Safari), and a
+  blob as the floor — and no test in this repo exercises any of them.
+  `test_downloads.py` pins the contracts by reading the source; the behaviour
+  needs a person with a large file. Confirmed by the operator on 2026-08-15:
+  Firefox, 180 MB, written to disk. Nothing multi-gigabyte has been measured
+
 **Corrections to remember:**
 - `punch_nat()` is **not** a NAT traversal stack — one UDP probe, no STUN, no candidate
   gathering, one ISP validated. **ICE/STUN (WebRTC) is the traversal path**, for native