fix(deploy): /tmp 占满把部署自己卡死了 —— 收构建暂存 + 构建带 -trimpath + 判据 ⑤

起因是用户让「清理一下」那批带仓库路径的残留。照着清理策略走时撞上更大的事实：
本机 /tmp 是 9.8G 的 tmpfs，**已 100% 满、可用 0 字节**，我自己的 `go build` 当场
ENOSPC 失败 —— 而部署的第一步就是构建。

## 1 谁把 /tmp 占满的（agentmail 自己的那份）

`redeploy-gateway.sh` 把网关构建到 /tmp 再 install 过去（为了原子替换），**用完没人删**：
每次部署留一个 24MB，实测 7 份 / 162MB。加上电子打包的中间物（squashfs-root 283MB、
pkgcheck/deb 291MB）、go-build-agentmail 缓存 172MB、4 个孤儿 go-build 工作目录 50MB
—— agentmail 名下约 960MB。另有别的产品的 /tmp/gocache 4.6G（TrueAgent 的
rebuild-plugins.sh 里 `export GOCACHE=/tmp/gocache`），不是本项目的，没动。

- prune-deploy-artifacts.sh 新增一类「构建暂存」，窗口 KEEP_BUILD_STAGES=1
  （正常路径下部署脚本自己会收，留下的只可能是失败那次，正好留现场）。
  自检 +1 项、变异验证过（把删除改成永不删 → 恰好那一项红）。
- 本次实际收：删除 8 项 / 释放 164MB（另加手动清 623MB 不可再生的中间物）。
- redeploy-gateway.sh 成功分支上收掉 $STAGE；失败/回滚分支**不删**（要留现场）。

## 2 残留里还藏着两处「旧真相」

- /etc/systemd/system/zcode.service.bak-20260912-145744（+ 同一次改动的
  zcode.service.d/10-dbus.conf.bak-…）里躺着 /home/program/agentmail/deploy/
  service-failure-notify.mjs —— 就是我上一封报「/etc/systemd 引用仓库 = 0 个文件」时
  **判据自己划掉了的那一类**（walk 里 `!name.includes('.bak')`）。已删（在线单元与
  deploy/systemd/ 逐字节一致，sha256 核对过），另外 4 个是别的产品的，没动。
- 判据 ① 因此放宽到含 .bak，并补了坏样本（.bak 里引用仓库路径必须判红）。
  上一封那句「0 个文件」的边界现在写进判据里了 —— 边界不说出口，就等于报了个假的 0。

## 3 -trimpath：标准目录部署只做了一半

Go 默认把源文件绝对路径编进二进制。对照实验（同一份源码、同一个 go，只差标志）：
带 -trimpath 0 处，不带 57 处 —— 而 19:05 那次部署产出的
/opt/agentmail/agentmail-gateway 里就有 57 处 /home/program/agentmail/…。
依赖确实没了，但**源仓库位置还印在产物上**。两个构建点都加上 -trimpath，
并新增判据 ⑤（已安装二进制不得含源码路径，两侧样本都验）。

判据 ⑤ 现在**是红的**，这是存量产物的实情：磁盘上那份要等下一次
redeploy-gateway.sh 才会被换掉。我没替它单独重启网关 —— 会掐断正在跑的会话。

（工作区是多会话共用的，本次只 add 了上面这 4 个 deploy/ 文件。）

deploy/redeploy-gateway.sh

@@ -127,11 +127,16 @@ fi
 say "3. 构建二进制"
 STAGE="/tmp/agentmail-gateway-build-$TS"
 # 先删再建：go build -o 到已存在的路径时可能拿到 stale 二进制（此坑中过多次）
+# ★ `-trimpath`：Go 默认把源文件的**绝对路径**编进二进制。2026-09-14 实测：本机
+# 历史二进制都是 trimpath 的（里面一处源码路径都没有），19:05 那次不是 ——
+# 于是生产件 /opt/agentmail/agentmail-gateway 里躺着 57 处 /home/program/agentmail/…。
+# 改标准目录部署是为了"运行时不再依赖源码目录"；没有 -trimpath 时这条只做到一半：
+# 依赖确实没了，但**源仓库位置还印在产物上**。判据在 check-deploy-drift（标准目录 ⑤）。
 run "rm -f '$STAGE'"
 if [ "$DRY_RUN" = 1 ]; then
-  printf '  [dry-run] (cd server && go build -o %s ./cmd/server)\n' "$STAGE"
+  printf '  [dry-run] (cd server && go build -trimpath -o %s ./cmd/server)\n' "$STAGE"
 else
-  ( cd "$REPO/server" && go build -o "$STAGE" ./cmd/server ) \
+  ( cd "$REPO/server" && go build -trimpath -o "$STAGE" ./cmd/server ) \
     || { bad "构建失败"; exit 1; }
   ok "构建完成 $(du -h "$STAGE" | cut -f1)"
 fi
@@ -248,6 +253,13 @@ if [ "$CHECK_FAIL" -gt 0 ]; then
 fi
 
 say "结论: 自动项全绿"
+# 构建暂存收尾。这份 24MB 副本只是为了「构建 → install」那一步的原子性，装完就没
+# 用了；原先没人删 ⇒ 每次部署在 `$TMPD` 留一份。2026-09-14 实测：7 份 / 162MB，
+# 而 `$TMPD` 是 9.8G 的 tmpfs —— 占满后**连部署自己的第一步都跑不动**
+# （go build 报 ENOSPC）。存量由 `deploy/prune-deploy-artifacts.sh` 按窗口收。
+# 只在这个**成功分支**上删：失败/回滚时那份二进制正是要留的现场，见上面的回滚分支。
+rm -f "$STAGE"
+ok "构建暂存已收（$STAGE）"
 echo "  回滚命令（留档 24 小时内有效）:"
 [ -n "$BINBAK" ] && echo "    install -m 0755 '$BINBAK' '$TARGET' && systemctl restart '$SERVICE'"
 [ -n "$DBBAK" ]  && echo "    install -m 0644 '$DBBAK' '$DB'   # 先 systemctl stop"