fix(deploy): keep BuildKit cache and use Huawei mirrors for API images

Gitea run 2828 validated, then publish hit the 60-minute deadline while
Aliyun apt/pip crawled at about 22 kB/s after a 72h cache prune on a
runner with 677 GiB free. Skip BuildKit prune when disk is above the
minimum, split API apt/pip layers, and point apt/pypi at Huawei Cloud.

docs/BUG_HISTORY.md

@@ -13039,3 +13039,19 @@
 - 相关记录：BUG-981、BUG-733、BUG-712；F3 同步确认 BUG-984 为 BUG-981 端到端阻塞项。
 - 复发自：BUG-733（同进程可证的等价关系被跨机 golden 代替）。
 - 修复版本：`25232ce4`，第三环境 review 通过；本次按产品授权合入 staging，详见 `docs/tasks/PROGRESS-rectification-cross-midnight-gate-fix-20260920.md`。
+
+## BUG-986 | staging publish 冷构建在 22 kB/s 镜像源下撞 60 分钟超时
+
+- 状态：investigating
+- 首次发现：2026-09-21
+- 最近更新：2026-09-21
+- 影响面：Gitea `backend-quality-gate` publish job、`deploy/railway-api.Dockerfile`、`deploy/reclaim-runner-disk.sh`
+- 用户现象：run 2828 的 validate 通过后，`Build and publish exact-SHA ACR images` 在 API 镜像 `pip install pandas` 期间被取消；结论 `failure`，`context deadline exceeded`。
+- 触发条件：向 staging 推送代码后 publish；runner 空闲 677 GiB，但距上次命中的 API 依赖层已超过 72 小时。
+- 根因：`reclaim-runner-disk.sh` 在磁盘充足时仍执行 `docker builder prune --filter until=72h`，丢掉 BuildKit 层缓存。随后 Aliyun debian/pypi 约 22 kB/s：`apt-get update` 9.4 MB 用 7 分、102 MB 软件包约 40 分，pyswisseph 6.9 MB 又 5 分，pandas 12.4 MB 下载未完成即达 publish 的 60 分钟上限。业务测试未失败。
+- 修复：磁盘不低于 `MINIMUM_FREE_GIB` 时保留 BuildKit 缓存；API 镜像 apt 与 pip 分两层，apt/pypi 改走华为云镜像（与 SWR 基础镜像同路径）。不改 workflow 超时、评分或确认门。
+- 验证：定向更新 `staging-backend-workflows.test.ts` 与 `test_railway_deployment.py`；远端以新 staging 门禁为准，本记录不提前标 resolved。
+- 防复发：磁盘充足时不得 prune BuildKit；API 依赖安装不得把 apt 与 pip 绑在同一层以致超时后整层作废。
+- 相关记录：BUG-142
+- 复发自：BUG-142（publish 超时预算；本次是缓存被过早丢掉后的冷构建）
+- 修复版本：待本修复合入 staging 的门禁 run