doc: record the real ks4 pull bottleneck — source disk, not the link

c8d759c claimed the ~125 Mbit/s seed rate was ks4's OVH uplink. That was
wrong, and measuring it says so: ks4 uploads at 609 Mbit/s, downloads at
900, and nas pulls 670 from OVH's network. WireGuard is not it either —
zero UdpRcvbufErrors, wg-crypt kworkers at ~2%, both hosts ~85% idle.

The limit is `data` sitting on sdb5, one 7200 rpm HGST 6 TB disk: during
the send it does 109 r/s at 14 MB/s with ~131 KB requests and a queue
depth of ~1.0, which is the random-IOPS ceiling of a single HDD reading a
fragmented 1.42 TiB dataset. 14 MB/s is ~112 Mbit/s on the wire, exactly
what we see, while the network sits idle.

Parallelism is the only lever and it works by disk queue depth, not
bandwidth: a second concurrent copy takes sdb from 14 to 21 MB/s and the
request size from 131 KB to 514 KB, lifting the tunnel from 113 to 153
Mbit/s. Recorded, along with the decision to keep the seed sequential —
one-off pass, incremental refreshes after, and incus-copy.sh is shared by
all three legs.

Also corrects the set size to the actual 1.42 TiB (~29 h, not ~31 h).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

nas/nas-install.md

@@ -715,6 +715,11 @@ Built 2026-09-16 — full runbook, corrections and gotchas:
 missed: nas needs `wireguard-tools` installed and a **managed `incusbr0`
 on `192.168.1.254/24`** (never `.1`), and the seed needs **`-p backup`**.
 
+The pull runs at ~14 MB/s (~112 Mbit/s) and that is **ks4's single
+spinning source disk, not the link or the tunnel** — measured, with the
+numbers, in [ks2/nas-seed.md](../ks2/nas-seed.md) §Bottleneck. Nothing to
+fix on the network side.
+
 ```sh
 systemd-run --unit=ks4-seed --collect \
   /bin/bash -c '/root/scripts/incus-copy.sh -r ks4 -s ks4backup -p backup \