服务端 zip 加一键部署脚本（cloudflared 安装 + 部署 + 公网，全自动）

用户要求：服务器端文件里放一个 .sh，双击就能检查 cloudflared 装没装、
自动部署、配好公网，以后全自动。

== 新增 ==

relay/deploy.sh        一键部署主脚本，7 步全自动：
                       环境检查 -> 装 cloudflared -> 部署程序 -> 网络调优
                       -> 写 4 个 systemd 服务 -> 配隧道 -> 启动自检打公网地址
relay/deploy-tune.sh   网络调优，可单独重跑：
                       keepalive 30/10/3 + 路径 MTU 探测 + MSS 1360
                       + 接口 MTU 1400 + mask networkd-wait-online
                       每一项都写明了实测依据

用法：
    bash deploy.sh                           复用已有凭据，全自动
    TUNNEL_TOKEN=eyJh... bash deploy.sh      Token 模式
    bash deploy.sh --hostname relay.你的域名  换域名
    bash deploy.sh --skip-tunnel             只装中转
    bash deploy.sh --help                    全部参数

重跑 = 升级；已有数据/配对码/管理密码/凭据/手改过的 config.yml 都不动。

== 自动化到什么程度 ==

* cloudflared 不在就自动下载装上（并校验能执行）
* 隧道支持两种模式：已有凭据文件、或 TUNNEL_TOKEN
* **不传 --hostname 且没有 Token 时明确提示要填**，不会静默用一个写死的值
  （用户明确说过：这个中转站是他自己用的，不对外开放，
   绝不能把私人域名烧成默认值）
* deploy-tune.sh 的 MTU 取 1400：路径 MTU 实测 1472，
  而 MSS 钳制只管 TCP、QUIC 走 UDP 完全不受保护；
  接口 MTU 降到 1400 后 QUIC 建齐 10 条连接从 28 秒缩到 12 秒

== 顺带修掉两个真 bug ==

1. write_tunnel_unit 写的文件名漏了 .service 后缀 ——
   文件写下去了但 systemd 完全看不见，enable 还会安静地失败。
2. 发布包一直缺 site_shots/（老 bug）：
   package_remote.py 用 iterdir() + is_file() 收文件，目录进不去。
   新机器装完官网截图全是 404。只有从 zip 解压真跑一遍才暴露。
   同时把 deploy.sh 里 site_shots 的检查降级成警告（缺截图不该让部署失败）。

另外给 deploy-tune.sh 清旧 MSS 规则的循环加了 10 次上限 ——
原写法在 -D 报成功但规则仍在时会死循环把整个部署卡死。

== 验证 ==

* _build/test_deploy_sh.sh        沙箱 65 项，全通过
* _build/test_zip_deploy.sh       从发布 zip 解压再跑，30 项，全通过
* _build/test_deploy_real.sh      **真机 Debian 上实测**（新增）：
    zip 解出 17 个文件 -> 语法/LF/无 BOM 通过
    --help 退出码 0 且无副作用、未知参数退出码 2
    沙箱安装成功、幂等重跑哨兵不被冲
    现有三个中转服务全程 active，自检 200

_build/CHANGELOG.md

@@ -1,3 +1,30 @@
+## 1.8.2
+
+- **下载快了几十倍**：安装包和 APK 改成由 Cloudflare 的边缘节点直接发送。
+  原来每次下载都要穿过隧道回到那台 4G 小机器上取文件，实测吞吐只有
+  3~67 KB/s，15 MB 的安装包根本下不动（还会中途断掉）。
+  现在改走边缘缓存：同一个文件实测从 **17 KB/s 提到 695 KB/s**，
+  APK 从 3 KB/s 提到 101 KB/s，并且不再消耗 4G 流量。
+
+- **跨网络连接更稳**：隧道改成**两种协议同时跑**
+  （QUIC 5 条 + HTTP/2 5 条，共 10 条连接）。
+  两种协议各有各的毛病 —— QUIC 尾部延迟好但建连容易超时，
+  HTTP/2 建连可靠但丢包时容易卡住。同时跑就是互相兜底：
+  一边犯病另一边还在服务。
+  实测 25 分钟连续可用率 **50/50 = 100%**（改之前是 96~98%）。
+
+- 修**网卡 MTU 和 QUIC 不匹配**：之前只给 TCP 做了 MSS 钳制，
+  而 QUIC 走 UDP 完全不受保护，包一大就被中间设备悄悄丢掉。
+  把网卡 MTU 降到 1400 之后，QUIC 建齐 10 条连接的时间从
+  **28 秒缩到 12 秒**。
+
+- 修**响应头不一致**：下载接口之前对 GET 和 HEAD 报的缓存信息不一样，
+  部分下载工具（IDM、迅雷）探测时会把文件误判成不可缓存甚至空文件。
+
+- 修**偶尔闪一下"已断开"**：原来只要有一次请求失败就立刻显示离线，
+  而 4G 链路上本来就有 2~4% 的偶发失败、一两秒就自己恢复。
+  现在改成**连续失败 3 次**才判离线 —— 真的断了仍然如实显示。
+
 ## 1.8.1
 
 - 修**局域网连接被中转劫持**（重要）：