feat(node): log what a transfer moved when it ends

One INFO line per lease: bytes, duration, rate, and the SCTP
association's window, round trip, losses and T3 expirations.

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

1 files changed, 17 insertions, 0 deletions

diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md
index 8d14e37..3820587 100644
--- a/docs/MESHBAY_DESIGN.md
+++ b/docs/MESHBAY_DESIGN.md
@@ -1385,6 +1385,23 @@ for the CLI and the Node page, and a periodic debug line. When someone reports a
 transfer stuck at "waiting", that line is the only thing that will say whether the
 node ever had them in a queue at all.
 
+**A transfer that ends says what it moved.** One INFO line per lease, however it
+ended (closed by the client, the connection gone, reclaimed as idle):
+
+```
+transfer: end download 1a2b3c4d done 213.0 MB in 35.2 s (6.05 MB/s) sctp cwnd=180 KB rtt=22 ms loss=31 t3=0
+```
+
+The bytes and the duration are the lease's own, from the first request under it
+to the last byte handed to the channel. The `sctp` figures are the association's
+totals since the connection opened, not the transfer's share: a connection
+carries several transfers and they share one congestion window. `loss` counts
+entries into fast recovery, each of which halves the window, and `t3` counts
+retransmission timeouts, each of which drops it to one packet (aiortc records
+neither; `transport/webrtc/sctp_stats.py` counts them). A window that stays at a
+few hundred KB with `loss` climbing is a transfer held back by the path, and
+before this line the journal could not say so.
+
 The lease module is free of asyncio and of the transport: it decides, and the
 caller does the I/O. A queue that reveals itself only through a DataChannel is a
 queue nobody can prove things about.