### Bugs found in the transport while reading it

These are correctness bugs in the congestion/RTT logic; fixing them is cheap and
should be the first thing done, because they undermine everything else:

1. **`avg_rtt` never updates after the first sample** (`impl.cpp:900-904`).
   `num_samples` is `unsigned int` (327680), so `num_samples/(num_samples-1)`
   is integer `1` and `1/num_samples` is integer `0`. The EMA becomes
   `avg = avg*1 + rtt*0`. Consequences: resend timeout is frozen at
   `clamp(2 × first RTT, 0.1, 2.0)` for the whole session; `jitter_avg` is
   frozen the same way; the RTT shown in the debug HUD is the RTT of the second
   packet ever ACKed. (Even as floats the formula is wrong: it should be
   `avg*(n-1)/n + rtt/n`.)
2. **Loss ratio is integer division** (`impl.cpp:778`).
   `successful_to_lost_ratio = packet_loss/packets_successful` with both
   `unsigned int`, and `packet_loss` is pre-clamped to `<= packets_successful`,
   so the ratio is exactly 0 or 1. The window therefore grows +100/s whenever
   at least half of it was used and loss was < 100%, and only ever shrinks when
   *every* packet in a 1 s window was lost/late. The 1 %/5 %/10 %/15 %
   thresholds are dead code. Net effect: effectively no congestion control;
   on a lossy link the window ramps to 2048 and stays there, generating retransmit
   storms that make lag worse.
3. **Send thread is not woken when ACKs partially open the window**
   (`threads.cpp:1241`): `TriggerSend()` only fires when
   `outgoing_reliables_sent` becomes empty. With a full window (e.g. 40 blocks =
   ~600 chunks queued in channel 2 behind a 64-packet window) the next batch waits
   for either the whole window to drain or the 50 ms timer or an unrelated
   `putCommand`. Throughput on high-RTT links is stop-and-go instead of pipelined.