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, 6 insertions, 1 deletions

diff --git a/docs/MESHBAY_NODE_PROTOCOL.md b/docs/MESHBAY_NODE_PROTOCOL.md
index 1355aaa..994c908 100644
--- a/docs/MESHBAY_NODE_PROTOCOL.md
+++ b/docs/MESHBAY_NODE_PROTOCOL.md
@@ -1456,6 +1456,10 @@ The **lease** is that object, and every transfer runs under one.
 * **A lease is scoped to the connection, never to the account.** It dies with the
   session, which is what makes the reclaim deterministic: a closed tab, a quit browser
   and a dropped network all arrive at the same teardown, and none of them needs a timer.
+  A second connection of the same device, as the same member of the same group, may
+  send `file_req` and `file_upload` under it; it can neither open nor close it and is
+  not sent its `transfer_state` (`MESHBAY_DESIGN.md` §5.5, "One transfer, several
+  connections").
 * **A lease covers a job, not a file.** A directory downloaded as a zip is dozens of
   files and *one* lease. One per file would deadlock against the member's own cap: the
   job cannot finish until it holds them all, and it can never hold more than its cap —
@@ -1519,7 +1523,8 @@ service one random id away.
 
 **A lease is what the node granted, not what the client called it.** `tr` is drawn by
 the client, so on `file_req` and `file_upload` it is a claim, resolved against the
-node's own record for this connection:
+node's own record for this connection, where "this connection" includes the other
+connections of its device to this group:
 
 | `tr` names | `file_req` | `file_upload` |
 |---|---|---|