multiport: bring docs and comments in line with the lane design

examples/config.yml still described lanes as extra tunnels with their own
handshakes, built lazily per routine. Rewrite it for lanes as sessions derived
from the base tunnel, and say that multiport.lanes only bounds sending.

In design/multiport.md, correct the partner-lane pairing (our lane s pairs
with the peer's lane s+portOffset, which laneBias lines up), the asymmetric
host example, the retry backoff, which reader owns what, the full-path
diagram, the demand-after-reset story and the metric descriptions.

Drop comments left over from earlier iterations: base traffic on "socket 0",
lanes picked by routine, lane handshakes, and multiport defaulting on.

udp/udp_linux_writebatch.go

@@ -22,10 +22,11 @@ import (
 // scratch WriteBatch packs mmsghdr entries into, plus the GSO capability
 // state probed at socket creation.
 //
-// One socket can have several senders: under multiport every routine writes its
-// base-session traffic to socket 0, and any routine may write to any lane
-// socket, since a packet's lane comes from its flow rather than from the routine
-// that read it. The scratch is per socket, not per sender, so mu serializes
+// One socket can have several senders: under multiport a routine writes lane s
+// traffic to the socket at its own group position on lane s's port, so every
+// socket is shared by the routines at that group position, one per port, since
+// a packet's lane comes from its flow rather than from the routine that read
+// it. The scratch is per socket, not per sender, so mu serializes
 // packing and draining. It is taken once per flush — a syscall's worth of work —
 // and only contends when two routines flush the same socket at the same instant.
 //