fix: accelerate staging Python installs

deploy/railway-api.Dockerfile

@@ -1,7 +1,9 @@
 FROM m.daocloud.io/docker.io/library/python:3.12-slim
 
 ENV PYTHONUNBUFFERED=1 \
-    PIP_NO_CACHE_DIR=1
+    PIP_NO_CACHE_DIR=1 \
+    PIP_INDEX_URL=https://mirrors.aliyun.com/pypi/simple/ \
+    PIP_DEFAULT_TIMEOUT=60
 WORKDIR /app
 
 COPY requirements.txt ./

docs/BUG_HISTORY.md

@@ -1577,9 +1577,9 @@
 - 用户现象：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 阶段和公开健康接口。
+- 修复：工作流保持单 job 构建发布部署链路；API 基础镜像改为已在 xiaoxin 完整拉取验证的 DaoCloud Python 3.12 slim，Web 基础镜像改为已完整拉取验证的华为云 DDN Node 22 alpine；API 构建使用实测最快的阿里云 PyPI 并设置 60 秒 pip 超时；远端 `ubuntu` 的 Docker 操作继续使用免交互 sudo。
+- 验证：修复前两个阿里云基础镜像地址均返回拒绝，Docker Hub 超时；替代 Python/Node 基础镜像均在真实 Runner 主机完成整镜像 pull。首次修复运行已进入 pip 阶段但官方源持续约 33 分钟；同机探测阿里云 PyPI 约 0.21 秒/350 KB/s，清华约 0.81 秒/90 KB/s，官方约 1.20 秒/88 KB/s。后续构建、ACR push、服务器 Compose 和健康检查继续按运行日志闭环。
+- 防复发：staging Dockerfile 的基础镜像必须在 xiaoxin 完整 `docker pull` 验证；Python 包源必须基于 Runner 实测选择并设置有限超时，避免网络异常无限占用工作流。
 - 相关记录：BUG-082、BUG-083、BUG-084
 - 复发自：BUG-082
 - 修复版本：待提交（本地可测）