fix: use reachable staging base images

deploy/railway-api.Dockerfile

@@ -1,4 +1,4 @@
-FROM registry.cn-hangzhou.aliyuncs.com/library/python:3.12-slim
+FROM m.daocloud.io/docker.io/library/python:3.12-slim
 
 ENV PYTHONUNBUFFERED=1 \
     PIP_NO_CACHE_DIR=1

deploy/railway-web.Dockerfile

@@ -1,4 +1,4 @@
-FROM registry.cn-hangzhou.aliyuncs.com/library/node:22-alpine
+FROM swr.cn-north-4.myhuaweicloud.com/ddn-k8s/docker.io/library/node:22-alpine
 
 WORKDIR /app/frontend
 COPY frontend/package.json frontend/package-lock.json ./

docs/BUG_HISTORY.md

@@ -1574,12 +1574,12 @@
 - 首次发现：2026-07-28
 - 最近更新：2026-07-28
 - 影响面：Gitea staging 镜像构建、ACR 推送与测试服务部署
-- 用户现象：质量验证通过后，发布步骤仍容易因镜像仓库、SSH/SCP 瞬时失败或 staging 分支在执行期间前移而失败；重新执行会无条件重建并推送两个镜像。
-- 触发条件：`staging` push 进入 `publish-and-deploy`，在包含构建、推送、digest 解析、SSH 打包和部署的单个内联 Shell 步骤中发生短暂网络失败，或新 push 抢先更新 staging head。
-- 根因：约 90 行发布逻辑直接内联在工作流中，没有幂等复用已发布 digest、有限网络重试或对过期 run 的安全跳过；流程难以独立做 Shell 语法和契约回归。
-- 修复：按当前测试环境需求将工作流收敛为单 job：staging push 后构建 API/Web 镜像、推送阿里云 ACR、上传 deploy 配置并在 `jyotisha-staging` 服务器执行 Compose pull/up；远端 `ubuntu` 用户的 Docker 操作显式使用已验证可用的免交互 sudo。
-- 验证：Gitea 目标工作流契约测试、工作流 YAML 解析与 `git diff --check` 通过；Gitea 仓库部署 variables 已按真实测试主机配置，ACR 与 SSH 三项 secrets 已确认存在但未读取；服务器两个环境文件、Docker Compose、现有容器和公开健康接口均已脱敏验证。由于工作流尚未提交和推送，本轮没有伪报新版本 Actions 部署成功。
-- 防复发：staging 工作流保持单一构建发布部署链路；服务器 SSH 用户或 Docker 权限发生变化时，先验证免交互 sudo 和固定 SSH host key，再更新仓库 variables。
+- 用户现象：staging 自动部署在构建 API 镜像时失败，阿里云 `library/python:3.12-slim` 返回 `pull access denied` / `insufficient_scope`；同路径的 Node 镜像也不可拉取。
+- 触发条件：`staging` push 后，Runner 使用 `registry.cn-hangzhou.aliyuncs.com/library/python:3.12-slim` 或对应 Node 地址解析基础镜像。
+- 根因：这两个阿里云 `library/*` 地址并非当前凭据可访问的公共镜像仓库；同时 xiaoxin 直连 Docker Hub 超时，导致不能简单换回官方短名称。
+- 修复：工作流保持单 job 构建发布部署链路；API 基础镜像改为已在 xiaoxin 完整拉取验证的 DaoCloud Python 3.12 slim，Web 基础镜像改为已完整拉取验证的华为云 DDN Node 22 alpine；远端 `ubuntu` 的 Docker 操作继续使用免交互 sudo。
+- 验证：修复前两个阿里云地址均返回拒绝，Docker Hub 超时；修复后替代 Python/Node 基础镜像均在真实 Runner 主机完成整镜像 pull。后续 Gitea 构建、ACR push、服务器 Compose 和健康检查继续按运行日志闭环，不提前标记部署成功。
+- 防复发：staging Dockerfile 的基础镜像来源必须在 xiaoxin 上用完整 `docker pull` 验证，不能只依赖域名可解析或 manifest 探测；工作流失败后继续检查实际 Gitea job 阶段和公开健康接口。
 - 相关记录：BUG-082、BUG-083、BUG-084
 - 复发自：BUG-082
 - 修复版本：待提交（本地可测）