Rebuild: edge:node --max-mbit caps a node's download

For workers on a shared line (poweredge-kantoor: 160 Mbit/s): the range
stream is read at most at the cap, TCP holds the coordinator back. The
cap is the node's, split over its processes (also EDGE_MAX_MBIT).
REBUILD.md: where workers run (connections set the speed; remote workers
take CPU off homelab).

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

REBUILD.md

@@ -45,6 +45,15 @@ search. Measured on the workstation (4 cores, 100 Mbit, Eweka):
   handles ~60 MB/s), under a core for web and Postgres. The line is the
   limit below ~0.7 Gbit/s: at 1 Gbit, ~3.5 days at best.
 
+Where workers run: total speed is set by the account's NNTP connections
+(~30 k articles/s each), not by worker CPU, so remote workers don't make
+it faster; they take CPU off homelab (at 1.25 M/s ~7 worker cores) at the
+cost of relaying the compressed XOVER (≤ ~0.7 Gbit/s up, homelab has 1
+Gbit/s). Plan: coordinator, web, Postgres and a few workers on homelab,
+most workers on batcave, a few on poweredge-kantoor with
+`edge:node --max-mbit` (e.g. 50 of its 160 Mbit/s ≈ 100–125 k articles/s;
+the cap is shared by the node's processes).
+
 Not built yet: re-running ranges for a retracted rule (the counts and rule
 versions are recorded), deployment (Dockerfile, compose), phase 2.