ci(runner): move every Gitea job to xiaoxin and let the gate reclaim its own disk

质量门跑在以 :host 模式注册的跳板机上，与无关生产服务共用文件系统，累积的按
SHA 打标镜像把根分区占满，PostgreSQL fixture 起不来，staging 连续 5 个提交发不
出去。把 12 个 job 统一迁到 xiaoxin，并在开跑前回收磁盘、余量不足时直接报磁盘
原因而不是让 23 个数据库测试代为失败。

当年据以搬迁的「xiaoxin 缺少 Docker Compose v2」是误诊：真实原因是用户级插件
目录里一个零字节 docker-compose 遮蔽了系统插件。

Co-authored-by: Cursor <cursoragent@cursor.com>

docs/BUG_HISTORY.md

@@ -3925,3 +3925,19 @@
 - 防复发：任何号称个人化的界面文案，其数据来源必须能追到当次计算或当次生成；用哈希在固定文案池里取模不是个人化，只是伪装成个人化。降级路径不得复制一份“看起来正常”的内容——生成失败时必须让用户看出没有生成成功，本次改成明确的一句话降级文案而不是通用建议。
 - 相关记录：BUG-265 无前序同类记录。与 BUG-263 同批，均为首页可见问题。
 - 修复版本：本地未提交候选
+
+## BUG-266 | staging 连续 5 个提交发不出去：质量门跑在跳板机上，把那台机器的磁盘占满，PostgreSQL fixture 全线起不来
+
+- 状态：resolved（本地修复，待提交与发布）
+- 首次发现：2026-08-18
+- 最近更新：2026-08-18
+- 影响面：`.gitea/workflows/` 全部 12 个 job 的 runner 归属、staging 质量门的数据库集成测试、`publish` 与 `Deploy staging` 的放行，以及跳板机上与本项目无关的 Nacos/MySQL/Redis/xxl-job 服务。
+- 用户现象：推到 `staging` 的提交一个都没上线。`https://staging.jyotisha.chat/api/health` 长时间停在 `561010f2`，而 `origin/staging` 已经前进了 4 个提交；Gitea 上 `validate` 连续 5 次 failure、`publish` 连续 5 次 skipped。
+- 触发条件：向 `staging` 推任何提交。与提交内容无关。
+- 根因：两层。其一，`manman-linux` runner 以 `manman-linux:host` 注册在跳板机上，job 直接跑在该机的宿主文件系统里，而质量门每次 push 都在本地 build 两个按 SHA 打标的镜像（`api-<sha>`、`web-<sha>`）且全流程没有任何镜像与构建缓存回收，累积到 1453 个镜像、根分区 99G 用满 94G、Avail 归零，于是 `docker compose up -d --wait postgres` 阶段 `initdb` 直接 `No space left on device`，23 个数据库测试级联失败。这台机器同时还跑着与本项目无关的生产服务，等于用别人的磁盘做构建。其二，当初把门禁从 `xiaoxin` 搬到跳板机的理由（ERR-103「xiaoxin 缺少 Docker Compose v2」）是误诊：`xiaoxin` 的 Docker Engine 一直正常，真正的原因是 `/root/.docker/cli-plugins/docker-compose` 有一个 2026-08-05 建立的**零字节文件**，用户级插件目录优先级高于系统目录，把系统里正常的 compose 插件遮蔽成 `exec format error`。误诊导致门禁被搬到一台不该承担构建的机器上，磁盘耗尽只是时间问题。
+- 修复：删掉 `xiaoxin` 上那个零字节插件占位文件并补装 `docker-compose-v2`（2.40.3），确认 `docker compose version --short` 与 `--project-name` 两项门禁能力检查通过；把 `.gitea/workflows/` 里 8 个仍指向 `manman-linux` 的 job 全部改为 `xiaoxin`（该机 20 核、61G 内存、877G 空闲）；新增 `deploy/reclaim-runner-disk.sh`，在 `validate` 与 `publish` 的 checkout 之后、拉取 Node 工具之前回收磁盘，并在空间仍不足 10 GiB 时带着原因 fail-closed，而不是让 23 个数据库测试去暴露磁盘问题。回收只针对没有任何容器持有的资源（`container prune --filter until=6h`、`name=^jyotisha-postgres-` 且 `dangling=true` 的卷、`network prune --filter until=6h`、悬空镜像、buildx 缓存，以及除当次 SHA 外的历史 `api-`/`web-` 标签），因此不会掀掉同一台 runner 上并发 job 的 fixture。
+- 验证：`staging-backend-workflows.test.ts` 38 项通过，其中新增两项——遍历 `.gitea/workflows/*.yml` 断言每个 `runs-on` 都是 `xiaoxin`（并禁止 `manman-linux` 重新出现），以及断言两个 job 都在 Node 工具之前调用回收脚本、脚本只回收未被持有的资源且低于阈值时 fail-closed；回收脚本纳入既有 shell 语法校验。`tsc --noEmit` 与该测试文件 ESLint 清洁。在 `xiaoxin` 上实测：compose 2.40.3 通过门禁的两项能力检查，且到 Gitea、ACR 镜像仓库、staging 主机 22 端口、npm/pypi/ECR/SWR 镜像源的出网全部可达。未做的验证：**回收脚本没有在真实 runner 上跑过一次**（当前 `xiaoxin` 有 877G 空闲，回收逻辑与阈值分支要等首次门禁运行才被真正执行）；跳板机上那 94G 与仍在运行的 `act_runner` 尚未清理下线。
+- 防复发：构建与测试不得跑在承载其他服务的机器上，也不得以 `:host` 模式共用其文件系统。质量门在开跑前自己保证磁盘余量，并把「磁盘不够」报成一句明确的失败，而不是让下游 fixture 去替它失败。runner 能力缺失必须定位到具体原因再决定搬迁：`docker compose` 不可用时要先查 `docker info` 的 client plugins 与用户级 `~/.docker/cli-plugins` 遮蔽，不能直接判定整台机器不支持 Compose——ERR-103 正是漏了这一步，代价是把门禁搬到错误的机器上并最终堵死发布。
+- 相关记录：ERR-103（`docs/research/pre_work_error_ledger.md`，同一 Compose 现象的误诊，本次给出真实根因）、ERR-105（同一台跳板机磁盘耗尽的基础设施记录）、BUG-264（本次被卡住无法发布的修复）
+- 复发自：无
+- 修复版本：本地未提交候选