fix(ci): reuse provider egress for backend-core artifacts

docs/reference/artifact-registry.md

@@ -60,7 +60,7 @@ bun scripts/cli.ts artifact-registry deploy-backend-core --commit <full-sha>
 
 真实 `install` 必须是幂等动作：创建远端目录，写入 CLI 渲染出的 config/compose/unit，执行 `systemctl daemon-reload`，启用并启动 `unidesk-artifact-registry.service`，然后运行与 `health` 相同的验收检查。若远端文件 hash 与期望不一致，install 可以覆盖由本 CLI 管理的 unit/config/compose，但不得删除 registry storage。
 
-`deploy-backend-core` 是 production backend-core 的 CD 入口。它必须先确认 D601 registry 中已经存在 `unidesk/backend-core:<commit>`，随后只执行短生命周期 relay、`docker pull`、retag、Compose `--no-build` recreate 和 live commit 验证；如果镜像不存在，应失败并要求先运行 CI artifact publication。
+`deploy-backend-core` 是 production backend-core 的 CD 入口。它必须先通过 CNCF Distribution HTTP API 确认 D601 registry 中已经存在 `unidesk/backend-core:<commit>`，随后通过 provider-gateway Host SSH 流式执行 `docker save | gzip`，在 master server 侧 `docker load`、retag、Compose `--no-build` recreate 和 live commit 验证；如果镜像不存在，应失败并要求先运行 CI artifact publication。
 
 `status` 和 `health` 通过：
 
@@ -100,7 +100,7 @@ docker compose -p unidesk-artifact-registry -f /home/ubuntu/.unidesk/artifact-re
 2. D601 CI 从 pushed Git checkout 构建 `unidesk/backend-core:<commit>`。
 3. CI 将镜像 push 到 `127.0.0.1:5000/unidesk/backend-core:<commit>`，并记录 image ref 与 digest。
 4. CD 在 master server 上确认目标 commit/tag/digest 存在。
-5. master server 通过受控、短生命周期的 localhost relay 从 D601 registry 拉取 commit-pinned 镜像。
+5. master server 通过 provider-gateway Host SSH 从 D601 registry 流式读取 commit-pinned 镜像 tar，不开放 registry 端口，也不使用第三方镜像托管。
 6. master server retag 为 Compose 使用的 backend-core 镜像名，并执行 `docker compose up -d --no-build --no-deps --force-recreate backend-core`。
 7. 部署后通过 image label、runtime env、health payload 验证 live commit。
 
@@ -108,7 +108,7 @@ docker compose -p unidesk-artifact-registry -f /home/ubuntu/.unidesk/artifact-re
 
 - source commit 来自 pushed Git，不来自 dirty worktree。
 - 镜像 tag 必须 commit-pinned，不能用 mutable latest 作为部署真相。
-- relay 是临时控制动作，不开放长期公网 registry。
+- provider-gateway SSH image stream 是临时控制动作，不开放长期公网 registry。
 - CI 可以有较多依赖；CD 只做拉取、retag、recreate 和 live commit 验证。
 - CD 不执行 `cargo build`、`docker build`、`docker compose build backend-core` 或任何等价的 Rust 构建动作。
 - `server rebuild backend-core` 仍不得作为 master server Rust 编译路径。

docs/reference/ci.md

@@ -26,7 +26,7 @@ Each commit CI run performs:
 
 `ci install` also prewarms the D601 k3s containerd runtime with the Tekton entrypoint/workingdir helper images, `oven/bun:1-debian`, `alpine/git:2.45.2` and `unidesk-code-queue:dev`. Missing images are pulled through the node-local provider-gateway WS egress proxy and then imported into native k3s containerd with digests preserved, so PipelineRun pods do not hang on external registry pulls. Sustained pull throughput below 1 MB/s is treated as a provider/main-server network or proxy degradation first, not as a Dockerfile or application failure.
 
-Git clone and dependency downloads inside the repo check task use `d601-provider-egress-proxy.unidesk.svc.cluster.local:18789`; the NO_PROXY list keeps the in-cluster read service, D601 TCP egress gateway and any in-cluster CI Git mirror on the cluster network.
+Git clone and dependency downloads inside the repo check task use `d601-provider-egress-proxy.unidesk.svc.cluster.local:18789`; the NO_PROXY list keeps the in-cluster read service and D601 TCP egress gateway on the cluster network.
 
 Private repository source authentication is part of the CI contract and follows `docs/reference/devops-hygiene.md`. If the repo-check task fails at `git clone` because credentials are unavailable, treat it as a CI infrastructure/auth gap, not as an application test result.
 
@@ -53,6 +53,7 @@ backend-core production image creation belongs to D601 CI, not to master server
 The CI artifact task must follow these rules:
 
 - Input revision comes from pushed Git and is resolved to a full 40-character commit. A dirty worktree or unpushed local tree must never be used as the image source.
+- Source fetch for this artifact uses the existing D601 GitHub SSH deploy identity and the node-local provider-gateway WS egress proxy at `http://127.0.0.1:18789`. D601 prepares a commit-pinned source export under `/home/ubuntu/.unidesk/ci/backend-core-artifacts/<commit>` before creating the PipelineRun; Tekton consumes that prepared source through a read-only hostPath and must not clone GitHub itself, mount GitHub credentials, use an in-cluster Git mirror, or accept an operator-uploaded source tree.
 - The source checkout, Rust build and Docker build run on D601 CI infrastructure. The master server must not run `cargo build`, `docker compose build backend-core` or `server rebuild backend-core` as part of production backend-core deployment.
 - The image is tagged with the source commit, for example `unidesk/backend-core:<commit>`, and pushed to the D601 artifact registry as `127.0.0.1:5000/unidesk/backend-core:<commit>`.
 - The image must carry at least `unidesk.ai/service-id=backend-core`, `unidesk.ai/source-repo`, `unidesk.ai/source-commit` and `unidesk.ai/dockerfile=src/components/backend-core/Dockerfile`.

docs/reference/devops-hygiene.md

@@ -44,6 +44,8 @@ Acceptable source access implementations are:
 - an in-cluster Git mirror managed by UniDesk; or
 - the same commit-pinned host-fetch boundary used by `ci run-dev-e2e`, where D601 fetches the manifest commit and passes only verified inputs into Tekton.
 
+For backend-core artifact publication, the required implementation is the host-fetch boundary: D601 uses the existing GitHub SSH deploy identity plus the node-local provider-gateway WS egress proxy, exports the requested commit to `/home/ubuntu/.unidesk/ci/backend-core-artifacts/<commit>`, and passes only that verified source directory into Tekton. This path must not be replaced by an in-cluster Git mirror, a third-party source mirror, an operator local checkout, or Tekton-mounted GitHub credentials.
+
 If a CI repo-check task fails at `git clone` because credentials are unavailable, classify it as a CI infrastructure/auth gap, not as an application test failure.
 
 ## Verification Priority