feat: spread a large download over eight connections

One WebRTC connection carries 5 to 6 MB/s whatever the line can do.
A leased download of 64 MB or more now opens seven more to its node,
and a lease serves the other connections of its device in its group.
Measured through the whole stack: 5 MB/s before, 24 after.

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

1 files changed, 16 insertions, 0 deletions

diff --git a/CLAUDE.md b/CLAUDE.md
index 01b9e84..24f024b 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -721,6 +721,22 @@ do. Read them before writing anything that touches the same mechanism.
   bottom edge of every element), not by reading the stylesheet, which is the
   standing rule here
 
+- **One WebRTC connection is 5 to 6 MB/s, and the reason is on the receiving
+  machine.** Downloads were slow on fast lines and the first diagnosis ruled
+  out SCTP congestion on a wrong premise ("two downloads from one group share
+  one connection, and they add up, so the limit is per download"): they were on
+  two connections. A browser's UDP socket has a 64 KB kernel buffer; a burst
+  overflows it, the kernel drops the packets (`Udp6RcvbufErrors` on the client,
+  nothing on the path), and aiortc halves its window each time. A native
+  receiver takes 37 MB/s on the same connection. Tuning the sender was measured
+  three ways and bought nothing, so a large download runs over eight
+  connections instead (`lanes` in `transport.js`, `docs/MESHBAY_DESIGN.md`
+  §5.5). Two things to keep: **the node's log could not answer the question**
+  until it logged one line per transfer (`transfer: end`, with the window, the
+  losses and the T3 expiries), and **loopback shows none of this**: 52 MB/s
+  with one connection and with eight, so only a browser on another machine
+  measures it
+
 ### More of the same, from four rounds of live testing
 
 - **A protocol harness cannot test the SPA.** Any second implementation of the