fix(R-1250): the line-test hold waits until the held app has really slowed down before asking the agent

Measured on demo-hp 2026-10-27: qBittorrent 5.2.4 kept sending at full speed for ~14 s after its limit fell to
1 KiB/s; the agent reads the uplink 5-15 s after the call, so every test on request was refused "not quiet"
(four tries in an hour, 4.0-4.2 Mbit/s). waitDrained polls each held app's own upload (qBittorrent up_info_speed,
Transmission uploadSpeed) until <= 16 KiB/s twice, 2 s apart, at most 90 s; an unreadable speed waits 20 s.
Tests TestR1250_* (five), red-proved by four mutations.

controller/README.md

@@ -3599,6 +3599,9 @@ it), holds the app at 1 KiB/s (Transmission 1 kB/s), calls `POST /host/line-test
 back — the household's own included; a change made during the test stays. A killed controller puts it back at start
 (`RecoverHold`, before any rule); the 50 % rule skips while a record exists. Proven on demo-hp with a real seed (felhom.eu
 `audits/dooplex-alarms-2026-10-24/`).
+**v0.346.0 (R-1250):** between the hold and the call the controller waits until every held app reports its own upload
+near zero (≤ 16 KiB/s twice, 2 s apart, at most 90 s; an unreadable speed waits 20 s) — qBittorrent sends at full
+speed for ~14 s after its limit falls, which made the agent refuse every test „not quiet" (measured 2026-10-27).
 **v0.344.0 (R-1261):** EVERY running seeder is held, one record per app (`upwatch.line_test_holds`); a record whose app
 was removed while held is dropped (it used to stop the 50 % rule for good); qBittorrent's hold names its slot
 (`up_limit` / `alt_up_limit` through `app/preferences` — `transfer/uploadLimit` follows the CURRENT speed mode), so a