docs: update hwlab gitea source authority references

docs/reference/hwlab.md

@@ -8,17 +8,17 @@
 - HWLAB legacy G14 DEV/PROD 已退役；`G14`/`G14-gitops`、`hwlab-dev`/`hwlab-prod`、17666/17667 和 18666/18667 不再是当前 source/runtime truth。退役状态和执行入口是 `bun scripts/cli.ts hwlab g14 retirement status|plan|execute --confirm`，细则见 `docs/reference/g14.md`。
 - HWLAB 指挥侧目标选择必须以 issue 或 CLI 中明确写出的 lane/node 为准；只有没有明确目标时，才读取 `config/hwlab-node-lanes.yaml` 的默认值。`config/hwlab-node-lanes.yaml` 是 node、lane、workspace、CI/CD repo、namespace、GitOps path、公网入口和 Secret sourceRef 的配置真相，长期参考不能把 G14、D601、v0.2 或 v0.3 写成隐藏默认。
 - HWLAB node-scoped `git-mirror` 的 GitHub upstream 标准传输使用 SSH，并由 `config/hwlab-node-control-plane.yaml` 的 `targets[].gitMirror.githubTransport.mode: ssh` 声明。D601/v03 固定通过 `GIT_SSH` wrapper 访问 `ssh://git@ssh.github.com:443/...`；node-global HTTP proxy 只作为 SSH CONNECT tunnel，不是 GitHub HTTPS auth/token transport。若运行面或 CLI 输出 `transport=https`、`GITHUB_TOKEN`、`git-mirror-github-token` 或 HTTPS token sourceRef，视为 control-plane drift/配置回归，先修 YAML 并执行 `hwlab nodes control-plane apply --node <node> --lane <lane> --confirm`，禁止改走 HTTPS、host workspace repair、fallback 或多来源仲裁。
-- HWLAB v0.3 CI/CD source authority 只来自 k8s git-mirror snapshot：`trigger-current` / `status` / build 先经受控 sync 创建并读取 `refs/unidesk/snapshots/hwlab-node-runtime/<branch>/<commit>`，不得把 host worktree、本地 fetch/pull、可变 branch ref 或 Pipeline 直连 GitHub 当 authoritative source。固定 workspace 只服务源码修改、PR 准备和 repo 内验证；rollout closeout 以 git-mirror snapshot、PipelineRun、GitOps/Argo revision 和 runtime revision 收口。完整操作口径见 `$unidesk-cicd`。
+- HWLAB v0.3 CI/CD source authority 由 YAML 中选中的 node/lane `sourceAuthority` 决定：legacy target 使用 k8s git-mirror snapshot；Gitea/PaC 迁移 target 使用 Gitea controlled mirror 和 immutable snapshot ref。`trigger-current` / `status` / build 只消费受控 source snapshot，不得把 host worktree、本地 fetch/pull、可变 branch ref 或 Pipeline 直连 GitHub 当 authoritative source。固定 workspace 只服务源码修改、PR 准备和 repo 内验证；rollout closeout 以 source snapshot、PipelineRun、GitOps/Argo revision 和 runtime revision 收口。完整操作口径见 `$unidesk-cicd`。
 - 进入任何 HWLAB lane 工作前，先解析目标 `--node <node> --lane <lane>` 或 issue 中的“目标分支/目标节点”，再用 YAML 解析出的 route/workspace/sourceBranch/kubeRoute/runtime namespace 做预检、快进和验证。例如 `目标分支: HWLAB v0.3` 且 `目标节点: D601` 时，工作面是 `D601:/home/ubuntu/workspace/hwlab-v03`、source branch 是 `v0.3`、k3s route 是 `D601:k3s`、runtime namespace 是 `hwlab-v03`、公网入口是 `https://hwlab.pikapython.com`。
 - D518 的 HWLAB v0.3 固定主 workspace 是 `D518:/home/ubuntu/workspace/hwlab-v03`，固定跟踪 `github/v0.3`。D518 上的源码修改、PR 准备和 repo 内验证必须在该固定 workspace 下创建任务级 `.worktree/<task>`；master server 本地 `/root/HWLAB`、一次性 clone 或未由 YAML 选中的路径只能做只读对照，不能承担 D518 开发 source truth。
 - JD01 的 HWLAB v0.3 固定主 workspace 是 `JD01:/root/workspace/hwlab-v03`，固定跟踪 `github/v0.3`。JD01 上的源码修改、PR 准备和 repo 内验证必须在该固定 workspace 下创建任务级 `.worktree/<task>`；如果固定目录尚未初始化，先建立该目录的固定 repo，再继续当前任务。
 - JD01 的出网、依赖拉取、k3s/bootstrap、git-mirror 和 web-probe 浏览器依赖都以 UniDesk YAML 中的 host-route/host-proxy 声明为准：`config/hwlab-node-control-plane.yaml` 的 `nodes.JD01.egressProxy`、`config/platform-infra/host-proxy.yaml#targets.JD01`，以及 `config/hwlab-node-lanes.yaml` 的 JD01 network/download/sourceWorkspace 配置。JD01 的 MDTODO、Cloud Web、web-probe 或 rollout 任务不是 Sub2API 任务；除非 issue/CLI 明确指向 Sub2API runtime、Codex pool 或 platform-infra sub2api target，不要把这类故障默认归因到 Sub2API，也不要把 JD01 egress 临时切到 Sub2API 路径。
 - JD01 的 node-local registry 是 k3s workload/PVC，不是 host Docker registry。`hwlab nodes control-plane infra status --node JD01 --lane v03` 应显示 registry workload ready、PVC bound、endpoint ready、`zeroSeeded=true` 和 `seededFromOldRegistry=false`；旧 host Docker `registry` 容器应保持停止。零种子 registry 迁移后，必须通过受控 `runtime-image preload` 和 `infra tools-image build/status` 补齐 BuildKit、runtime/base 和 tools image，再把 HWLAB/AgentRun status 与 web-probe smoke 作为可用性证据。
 - HWLAB 项目内长期规则入口仍以目标 repo 的 `AGENTS.md` 为准。进入已解析的目标 workspace 后，必须重新读取该 workspace 的规则文件；不能只凭主 server 的压缩上下文继续操作。
-- 每次开始 node/lane 源码修改、PR 准备或 repo 内验证前必须通过 YAML-first 受控入口检查并同步目标 workspace：`bun scripts/cli.ts hwlab nodes control-plane source-workspace sync --node <node> --lane <lane> --confirm`，再用 `source-workspace status` 读取 clean、branch、remote、HEAD 和依赖状态。该入口从 `config/hwlab-node-lanes.yaml#lanes.<lane>.targets.<node>.sourceWorkspace` 读取 workspace remote、proxy env、identityTarget/identityId 和 up-to-date policy，并复用 `config/deploy-ssh-identities.yaml` 分发非交互 GitHub SSH 身份；不要把裸 `trans <node>:<workspace> git fetch ...` 当成正式预检入口。CI/CD trigger、status 和 rollout source closeout 仍以 k8s git-mirror snapshot 为准。
+- 每次开始 node/lane 源码修改、PR 准备或 repo 内验证前必须通过 YAML-first 受控入口检查并同步目标 workspace：`bun scripts/cli.ts hwlab nodes control-plane source-workspace sync --node <node> --lane <lane> --confirm`，再用 `source-workspace status` 读取 clean、branch、remote、HEAD 和依赖状态。该入口从 `config/hwlab-node-lanes.yaml#lanes.<lane>.targets.<node>.sourceWorkspace` 读取 workspace remote、proxy env、identityTarget/identityId 和 up-to-date policy，并复用 `config/deploy-ssh-identities.yaml` 分发非交互 GitHub SSH 身份；不要把裸 `trans <node>:<workspace> git fetch ...` 当成正式预检入口。CI/CD trigger、status 和 rollout source closeout 仍以选中 `sourceAuthority` 解析出的受控 source snapshot 为准。
 - k3s 操作必须使用 YAML 解析出的 route 语法，例如 `trans D601:k3s ...` 或 `trans G14:k3s ...`。第一个 route token 必须定位分布式目标，后续 token 才是 operation。
 - D601 node-scoped runtime（例如 `D601` + `v0.3`）不是 legacy；只要 issue/CLI 明确选择 D601 node/lane，就按 YAML 中的 D601 target 执行。D601 legacy 只指旧 DEV/迁移/回滚对照路径（如 `/home/ubuntu/workspace/hwlab-dev`、16666/16667 或历史 `deploy/deploy.json` wrapper），必须由 issue/CLI 明确写成 legacy/迁移/回滚才使用。
-- `/root/HWLAB`、`/workspace/hwlab`、`/home/ubuntu/hwlab`、`/tmp/hwlab-*`、无关 runner clone、master-server checkout 或未由 YAML 选中的 workspace 都不能作为当前 HWLAB 开发 source truth；CI/CD source authority 只看 k8s git-mirror snapshot。
+- `/root/HWLAB`、`/workspace/hwlab`、`/home/ubuntu/hwlab`、`/tmp/hwlab-*`、无关 runner clone、master-server checkout 或未由 YAML 选中的 workspace 都不能作为当前 HWLAB 开发 source truth；CI/CD source authority 只看选中 YAML `sourceAuthority` 的受控 source snapshot。
 
 ## 关键 GitHub 入口