修正 CI 缓存部署的网络地址与验收流程

区分任务容器、Runner 网关和宿主源码拉取地址
记录内层 Docker 独立地址池与遗留网络定向清理方式
补充真实任务网络中的源码拉取和 API 连通性验收
同步团队开发流程中的部署约定

deploy/container/README.md

@@ -138,7 +138,13 @@ install -m 600 deploy/container/gitea-ci-cache.config.example.json /etc/genarrat
 docker compose -f deploy/container/gitea-runner-fetch-gate.compose.yml up -d
 ```
 
-**首次接入或从不跟踪任务的旧网关升级，需要空闲维护窗口**：确认无活跃 CI 且暂停新 CI 触发，再备份现有 runner 配置和注册文件，在 runner 部署的 `GITEA_INSTANCE_URL` 及 `/data/.runner` 的 `address` 中改用 `http://gitea-runner-fetch-gate:8080`，保留其余注册字段。同时在 `/data/config.yaml` 的 `runner.envs` 中设置 `GENARRATIVE_GITEA_REPOSITORY_URL: "http://gitea:3000/GenarrativeAI/Genarrative.git"`，与维护器的 `repository_url` 一致，沿用现有 job 已可达的内部 Git 通道。此专用变量也覆盖旧 PR 的 checkout；不要用同名 GITHUB_SERVER_URL 环境变量代替，Runner 会再次覆盖它。按原流程重启并验证 runner 注册。
+**首次接入或从不跟踪任务的旧网关升级，需要空闲维护窗口**：确认无活跃 CI 且暂停新 CI 触发，再备份现有 runner 配置和注册文件，在 runner 部署的 `GITEA_INSTANCE_URL` 及 `/data/.runner` 的 `address` 中改用 `http://gitea-runner-fetch-gate:8080`，保留其余注册字段；runner 进程的 `NO_PROXY` / `no_proxy` 必须加入 `gitea-runner-fetch-gate`。同时在 `/data/config.yaml` 的 `runner.envs` 中设置 `GENARRATIVE_GITEA_REPOSITORY_URL: "http://genarrative-station/git/GenarrativeAI/Genarrative.git"`，与维护器的 `repository_url` 一致。当前 job 通过 `--add-host=genarrative-station:172.30.0.3` 访问现有 actions gateway，job 的代理例外保留 `genarrative-station`；runner 自身能访问的 `http://gitea:3000` 不代表内层 job 也能访问。此专用变量也覆盖旧 PR 的 checkout；不要用同名 GITHUB_SERVER_URL 环境变量代替，Runner 会再次覆盖它。按原流程重启并验证 runner 注册。
+
+维护器的 `clone_url` 属于宿主网络：当前 Gitea 将容器 3000 映射到宿主 3003，因此使用 `http://127.0.0.1:3003/GenarrativeAI/Genarrative.git`，避免本机完整 clone 绕公网导致 900 秒超时；不要把这个 loopback 地址传给 job。其它部署必须按实际端口核实。`api_url` 仍使用 HTTPS 公开 API 地址。
+
+内层 Docker 的默认地址池必须避开外层 `gitea-actions` 的 `172.30.0.0/24` 和 egress 的 `172.31.0.0/24`。当前 `/opt/gitea-stack/config/runner-dockerd-run` 在 dockerd 参数中设置 `--default-address-pool base=10.240.0.0/16,size=24`，每个 job 获得独立 `/24`。变更在 runner 重启后生效，只影响新网络；先逐个检查并定向删除无容器引用的 `GITEA-ACTIONS-TASK-*` 遗留网络，不能全局 prune。取消或强制停止 runner 可能留下空网络，默认 Docker `/16` 地址池累积到 `172.30.0.0/16` 会截走网关流量。
+
+恢复领取前，必须在内层 Docker 新建与 job 相同的 bridge，使用现役 CI Image ID、相同 host 映射和代理环境，实际执行 `genarrative-gitea-checkout` 并访问 `https://git.genarrative.world/git/api/v1/version`；同时确认新网络使用上述 `/24` 地址池。仅宿主 `git ls-remote`、runner 注册成功或 FetchTask 路由通过，均不能替代 job 网络验收。
 
 不能仅改磁盘文件却不让进程加载；维护器还会检查独立 checkout URL，并确认入口实际见到了当前容器本次启动后的 FetchTask 来源 IP。此一次接入不由维护器冒险猜测空闲，也不对运行中 CI 动手。实例 API 根地址仍使用配置中的 HTTPS Gitea 地址，不能指向只支持 runner RPC 的入口。上传脚本从独立 `GENARRATIVE_GITEA_REPOSITORY_URL` 推导真实 Gitea 地址，使用本任务临时凭据调用原生 V4 API；不依赖被网关覆盖的 `GITHUB_SERVER_URL` / `ACTIONS_RUNTIME_URL`。Gitea 1.26.4 的仓库 REST 下载接口只支持 V4，不能换回 V3 上传。宿主下载只跟随同一 HTTPS Gitea origin 的签名重定向，不转发长期 Token；如配置外部对象存储直出，需另行适配下载来源。
 

deploy/container/gitea-ci-cache.config.example.json

@@ -1,8 +1,8 @@
 {
   "api_url": "https://git.genarrative.world/git/api/v1",
   "repository": "GenarrativeAI/Genarrative",
-  "repository_url": "http://gitea:3000/GenarrativeAI/Genarrative.git",
-  "clone_url": "https://git.genarrative.world/git/GenarrativeAI/Genarrative.git",
+  "repository_url": "http://genarrative-station/git/GenarrativeAI/Genarrative.git",
+  "clone_url": "http://127.0.0.1:3003/GenarrativeAI/Genarrative.git",
   "runner_container": "gitea-runner",
   "token_file": "/etc/genarrative-ci-cache/api-token",
   "state_dir": "/var/lib/genarrative-ci-cache",