docs: update v02 git mirror performance baseline

docs/reference/g14-cicd-performance.md

@@ -44,19 +44,22 @@ G14 Tekton 日志中的分段耗时统一使用 JSON 行事件：`event="g14-cic
 | `v0.2` pre-mirror 9-build | 27 | 391s | 92s | 92s | 9 个保留服务 build task，GitHub/GitOps 读路径仍混在 prepare 阶段。 |
 | `v0.2` mirror 9-build | 1 | 277s | 51s | 75s | source clone 走 mirror，样本量低，只作为趋势样本。 |
 | `v0.2` env-reuse code-only/no-build | 3 | 172s | 49s | 0s | 8 个 task 成功、9 个 build branch skipped；只更新 boot commit/code identity。 |
+| `v0.2` env-reuse code-only/no-build，source+catalog mirror | 2 | 143.5s | 37.5s | 0s | `prepare-source` 的 source clone 和 GitOps catalog lookup/fetch 都走 mirror；9 个 build branch skipped。 |
 
-同口径 P50 加速效果：`v0.2` pre-mirror 9-build 到 env-reuse code-only 约 `2.27x`；`v0.2` mirror 9-build 到 env-reuse code-only 约 `1.61x`；`G14` legacy full build 到 `v0.2` env-reuse code-only 约 `2.98x`。这些倍率只描述已观测的运行类型，不外推到 DB migration、Secret 变更或 runtime 架构变更。
+同口径 P50 加速效果：`v0.2` pre-mirror 9-build 到 env-reuse code-only 约 `2.27x`；`v0.2` pre-mirror 9-build 到 source+catalog mirror env-reuse code-only 约 `2.73x`；`v0.2` mirror 9-build 到 source+catalog mirror env-reuse code-only 约 `1.93x`；`G14` legacy full build 到 source+catalog mirror env-reuse code-only 约 `3.57x`。这些倍率只描述已观测的运行类型，不外推到 DB migration、Secret 变更或 runtime 架构变更。
 
-git mirror 本身不是 50 秒级瓶颈。集群内临时 pod 对 `http://git-mirror-http.devops-infra.svc.cluster.local/pikasTech/HWLAB.git` 的实测结果为：`git ls-remote refs/heads/v0.2` P50 约 19ms，`git clone --no-checkout` P50 约 787ms，`git checkout --detach` P50 约 64ms。Tekton `prepare-source` 的 48-65s wall time 是混合耗时，包含 entrypoint/PVC/workspace 启动、proxy/npm probe、source clone、GitOps catalog 读取、`npm ci` 和脚本收尾，不能直接归因给 mirror。
+git mirror 本身不是 50 秒级瓶颈。集群内临时 pod 对 `http://git-mirror-http.devops-infra.svc.cluster.local/pikasTech/HWLAB.git` 的早期实测结果为：`git ls-remote refs/heads/v0.2` P50 约 19ms，`git clone --no-checkout` P50 约 787ms，`git checkout --detach` P50 约 64ms。修复 atomic/manual sync 后，对已发布 commit 的 `git ls-remote` 为 49-53ms，`git cat-file <commit>^{tree}` 为 40-43ms。Tekton `prepare-source` 的 37-65s wall time 是混合耗时，包含 entrypoint/PVC/workspace 启动、proxy/npm probe、source clone、GitOps catalog 读取、`npm ci` 和脚本收尾，不能直接归因给 mirror。
 
-已观测的 prepare-source 内部分段：source clone 经 mirror 后约 0.9-1.1s；GitOps catalog 读取若仍走 canonical GitHub SSH 约 9s；`npm ci --ignore-scripts` 约 15-18s；剩余为 Tekton entrypoint、PVC/workspace、探针和 shell/Node 启动固定开销。只读 catalog lookup/fetch 应与 source clone 一样走 `git-read-url` mirror；GitOps promotion push 仍必须走 canonical GitHub remote。
+已观测的 prepare-source 内部分段：source clone 经 mirror 后约 0.9-1.1s；GitOps catalog 读取若仍走 canonical GitHub SSH 约 9s；catalog lookup/fetch 改走 mirror 后，`catalog-ls-remote` 为 47-58ms，`catalog-fetch` 为 92-113ms，`catalog-fetch` JSON timing 总计 277-348ms；`npm ci --ignore-scripts` 约 15-18s；剩余为 Tekton entrypoint、PVC/workspace、探针和 shell/Node 启动固定开销。只读 catalog lookup/fetch 与 source clone 一样走 `git-read-url` mirror；GitOps promotion push 仍必须走 canonical GitHub remote。
+
+`devops-infra` git mirror sync 是写侧刷新成本，不是 CI 读路径成本。mirror 不设 CronJob，标准入口是 `bun scripts/cli.ts hwlab g14 git-mirror sync --confirm` 手动创建一次性 Job；旧 `git-mirror-hwlab-sync` CronJob 已删除。2026-05-29 的最终手动 sync 样本中，Job 脚本内 total 为 12.1s，其中 GitHub fetch 4.6s、object closure validate 6.0s、publish update-ref 1.1s、fsck 0.12s；UniDesk route 从创建 Job 到返回日志总计约 18.9s。这个 12-19s 不代表 mirror clone 速度，而是 GitHub SSH fetch、对象校验、Kubernetes Job 启动/轮询和日志采集的总成本。
 
 当前滚动基线量级：
 
 | 阶段 | 典型范围 | 说明 |
 | --- | --- | --- |
 | Source trigger | 0-60s | poller 每分钟运行一次；平均等待应接近 30s。 |
-| `prepare-source` | 75-175s | 主要由 fresh clone、GitOps catalog fetch 和 `npm ci` 组成；这是很多单组件运行里的最大固定成本。 |
+| `prepare-source` | 37-175s | source+catalog mirror 的 code-only 样本为 37-38s；旧路径、多 build 或未优化样本可到 75-175s。当前主要固定成本已转为 Tekton/PVC/entrypoint 和 `npm ci`。 |
 | Primitive validation | 每项 5-10s | source 准备后并行运行，目前不是主要瓶颈。 |
 | `plan-artifacts` | 6-10s | 当前可接受，重点是保持只读和确定性。 |
 | Reused service TaskRun | 每项 8-12s | fan-out wall time 接近最慢复用 task，但 unchanged services 仍会启动 build-shaped pod。 |