纠正一个传出去的错误结论：不是「运营商封了 UDP」

我在给部署脚本的指示里写过：

    实测这条线路上运营商对 UDP 有限制 ——
    12 个 Cloudflare edge IP：TCP 12/12 通、UDP 0/12 通

它照这个把注释写进了 relay/deploy.sh。

**但这个测量是无效的。** relay-stability 后来自己纠正了：
那个 UDP 探测包是手搓的简化包，格式不对，
Cloudflare 本来就不该回应它 —— 「0/12 无回应」什么都证明不了。

用 cloudflared --loglevel debug 跑临时实例，真相是：

    UDP Connectivity  region1/region2  PASS  QUIC connection successful
    SUMMARY: Environment is healthy. cloudflared will use 'quic'
    Registered tunnel connection        （握手 1 秒）

**UDP 完全通。**

真因是：QUIC 建连要 6+ 个包往返，而 TCP 的 SYN 只有 3 个包、
内核还会按 1s/2s/4s 激进重传。约 5.4%/包 丢包下：

    (1 - 0.054)^6 ≈ 72%     <- 和实测的 72% 对得上

所以 QUIC 的弱点在「连不上」，不在「连上之后不好」；
一旦连上，它没有 TCP 的跨流队头阻塞，反而更稳。

结论的**用途**没变（还是要两条协议一起跑），但留着错误的根因注释会：
  * 误导后人以为 UDP 被封 -> 可能做出「干脆别用 QUIC」的错误决定
  * 掩盖真正可优化的方向（QUIC 握手对丢包敏感是链路物理属性，
    只能靠 HTTP/2 兜底来绕，不是「运营商限制」）

改动：relay/deploy.sh 两处、_build/test_deploy_sh.sh 一处。

教训记一笔：**手搓协议包去探测可达性非常容易得出错误结论** ——
那个包格式不对，对方根本没义务回应。要么用官方工具的自检
（cloudflared 自己会打 UDP Connectivity PASS/FAIL），
要么别下结论。

_build/rp_pc_long.tsv

@@ -152,3 +152,24 @@ time	code	ms
 2026-10-07 18:14:59	200	1089
 2026-10-07 18:15:15	200	987
 2026-10-07 18:15:31	200	999
+2026-10-07 18:15:48	200	1426
+2026-10-07 18:16:04	200	1222
+2026-10-07 18:16:20	200	1397
+2026-10-07 18:16:37	200	1127
+2026-10-07 18:16:53	200	1010
+2026-10-07 18:17:09	200	1140
+2026-10-07 18:17:25	200	1032
+2026-10-07 18:17:41	200	1367
+2026-10-07 18:17:57	200	1111
+2026-10-07 18:18:13	200	1285
+2026-10-07 18:18:30	200	1169
+2026-10-07 18:18:46	200	1380
+2026-10-07 18:19:02	200	1017
+2026-10-07 18:19:18	200	1121
+2026-10-07 18:19:34	200	1184
+2026-10-07 18:19:51	200	1386
+2026-10-07 18:20:07	200	1351
+2026-10-07 18:20:23	200	1381
+2026-10-07 18:20:40	200	1432
+2026-10-07 18:20:56	200	1468
+2026-10-07 18:21:13	200	1462