纠正一个传出去的错误结论：不是「运营商封了 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），
要么别下结论。

_tests/verify_all.ps1

@@ -400,6 +400,17 @@ $stageOut = & python (Join-Path $root "_tests\check_encoding.py") 2>&1
     Show-Fails $stageOut
 Record "编码与换行" ($LASTEXITCODE -eq 0)
 
+# ---------------------------------------------------------------- 3a5
+Banner "3a5/7 局域网/中转对比基准（防测试自己骗人）"
+# 这个基准一度是红的，而且报告里写着「这是中转链路的产品 bug」——
+# 实际是基准自己有两个 bug：两条路用了同一个配对码、
+# 以及 attach 用了旧码（打到已经死掉的设备上）。
+# 一个已经修好的产品因此背了黑锅，而且症状（连接超时）
+# 看起来完全像产品问题，极难自己发现。
+$stageOut = & python (Join-Path $root "_tests\test_lan_bench_guard.py") 2>&1
+    Show-Fails $stageOut
+Record "局域网对比基准" ($LASTEXITCODE -eq 0)
+
 # ---------------------------------------------------------------- 3b
 Banner "3b/7 Python 静态检查（pyflakes）"
 # 这一层能抓到"运行到某行才炸"的问题。