Carry the ack-latency loss floor on a pinned quiche

[davidtorcivia]

The forensics proved the sender's loss detector invents the wire's losses: the ack feedback loop is structurally 1.5-3ms against a ~1.25ms loss delay, and cubic pays for tens of thousands of phantom losses per gigabyte. This pins quiche to a one-commit fork (0.24.9 plus an enable_ack_latency_loss_floor flag, off by default there, on in the pump) and records the decision as ADR-0028. The same change is upstream as cloudflare/quiche#2568; the pin dissolves when it lands. Five wire runs on this code: median 8.83 Gbit/s against 7.9-8.0 stock, declarations down 94%.

[davidtorcivia]

Review (sonnet) verified the pin end to end: the fork rev is exactly one commit atop the 0.24.9 tag, the Cargo.lock diff is only the source swap (octets 0.3.6 to 0.3.4 is the tag's own path-dep version, not drift), the flag reaches both roles through the shared Config::build, no test asserts loss behavior that could flake, and upstream 2568 is real and open. One blocking find, fixed in the second commit: deny.toml sets unknown-git to deny and only allowed the msquic source, so cargo deny in validate would have failed on the fork URL. The allow-git entry is commented to leave with the pin.

[davidtorcivia]

Merged with all 41 checks green. The push after review added the deny.toml allowance the fork pin needs; nothing else changed. Post-merge state: main 7785bf2, the pump runs the ack-latency loss floor on the pinned rev, and the exit condition is upstream cloudflare/quiche#2568.