Pin the merged artifact-store and plan commits

Why: Dev has to follow the commits that landed on Backend and Documents main, which share trees with the drilled objects.
Evidence: Backend dc736e339d01 tree 498f61947564 equals 46073d30. Documents 05c13a42b14d tree equals 5335499. GATE run 2794 on 6d8b746 succeeded before this pin.
Impact: gitlinks move to the merge commits. Second-instance writes stay closed.
Refs: #186 #92 #497
Co-authored-by: Cursor <cursoragent@cursor.com>

.task/fix-u7-k4-artifact-upload.md

@@ -95,10 +95,10 @@
 
 ## 合入与清理
 
-- Review 记录：NOT_RUN（审阅智能体/平台身份、base/head、结论、问题闭合及重放依据）
-- 冲突记录：NOT_RUN（最新目标同步、冲突处置、组合兼容核验及复审/补测）
-- CI 记录：NOT_RUN（当前 HEAD 完整 SHA、全部必需检查、运行链接、执行身份及 GATE 结果）
-- 合入记录：NOT_RUN（交付授权范围、PR、被核验 HEAD、合入 SHA、目标分支及内容核验）
+- Review 记录：独立审阅（未参与实现）approve，无 blocker。对象 Backend `46073d30a575e115aeb9112fd8674160dc2134d5`（PR #186）与 Dev `6d8b746e92f6adbea7ca751e603eab80d568e954`（PR #497）。一条 note：带类型空指针测试覆盖 `createArtifacts=true`。评论 https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/497#issuecomment-5274
+- 冲突记录：`make task-sync` 并入 origin/main `5aebedebeb963b5c01f39fd9122ec60dbe6d34d3`，无冲突。Backend 与 Documents 的 main 在合入前分别停在各 PR 的 base，合并提交与 PR head 同树。
+- CI 记录：Dev `6d8b746e92f6adbea7ca751e603eab80d568e954` 的 [运行 2794](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/actions/runs/2794) 中 test（job 4050）、test-pg（job 4051）、svc-realcombo（job 4052）均为 success（GATE）。Backend `46073d30` 的 [运行 2783](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Backend/actions/runs/2783/jobs/4031) vet-and-test success（GATE）。Documents 无 CI。重钉后的 Dev HEAD 另等当前 CI，合入消息引用该运行。
+- 合入记录：Backend [#186](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Backend/pulls/186) 合入 `dc736e339d01c59e658abc63c81909059bd6ea02`，树 `498f61947564c67caa9d401566b607f4c2a6a5e1` 与 `46073d30` 相同，不重跑演练。Documents [#92](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/92) 合入 `05c13a42b14d70f878cc8a51c543e018a7f7a663`，树与 `5335499` 相同。Dev PR #497 待重钉后的当前 HEAD CI 再合入。
 - 清理记录：NOT_RUN（授权依据、写者退出确认、worktree/分支/任务卡处置）
 
 <!-- Local receipt: SELF. Digests detect corruption; they do not authenticate a reviewer or CI. -->

docs/release-multi-instance.md

@@ -39,7 +39,7 @@
 | C2 | 双进程**负载**下互相不拖累（热点会话/命令时延） | 上表 B2/B3 均 `--instances 2`（VU 粘滞 + 跨实例读 + 热点 409 入 expected_contention；非热点读阈值全过） | ✅ SELF（2026-10-12）；非 GATE/REPLAY |
 | C3 | 双主机（跨机网络）验证：同套验收在两台主机执行 | A6 的 AGENT_BIN/DSN 指向远端；需用户指定第二主机 | ❌ 待资源 |
 | C4 | 故障演练：PG 断连/Redis 断连恢复（RTO≤15min） | `tests/ops/run_fault_drill.sh --fault all`；results `fault-20261012-142734`。pg-stop 与 pg-kill 的 F1–F5 均过，RTO 不到 1 秒且未重启应用。Redis：共享限额 20，断连期间按实例合计约 40，拉起后回到 20；无 5xx。G4 降级不可见、G5 启动时 Redis 不通则拒绝，记为发现 | ✅ SELF（2026-10-12）；非 GATE/REPLAY |
-| C5 | 备份恢复演练（RPO≤5min/RTO≤60min，pg_dump+物理备份） | `tests/ops/run_backup_drill.sh`。2026-10-12 `backup-20261012-153441` 的库恢复过、K4 因空 `*S3` panic 失败。2026-10-13 在 Backend `46073d30`、Dev `a83588dd` 上重跑 `backup-20261013-013354`：K1–K7 过，RPO 65s，RTO 3s；K4 为 5 个工件 sha256 一致且跨用户项目/工件访问均为 404。静态加密、凭据演练记 N/A；归档与数据同盘 | ✅ SELF（2026-10-13）；非 GATE/REPLAY |
+| C5 | 备份恢复演练（RPO≤5min/RTO≤60min，pg_dump+物理备份） | `tests/ops/run_backup_drill.sh`。2026-10-12 `backup-20261012-153441` 的库恢复过、K4 因空 `*S3` panic 失败。2026-10-13 在 Backend `46073d30`（合入 `dc736e3`，同树）、Dev `a83588dd` 上重跑 `backup-20261013-013354`：K1–K7 过，RPO 65s，RTO 3s；K4 为 5 个工件 sha256 一致且跨用户项目/工件访问均为 404。静态加密、凭据演练记 N/A；归档与数据同盘 | ✅ SELF（2026-10-13）；非 GATE/REPLAY |
 
 ## 放行结论（当前）
 

docs/svc.md

@@ -725,7 +725,7 @@ pg_ctl -D /secure/restore-pgdata -l /secure/postgres.log -t 600 -w \
 
 `-k` 必须是短路径。结果目录下的 socket 路径超过 107 字节时，postmaster 会拒绝启动（同日 `backup-20261012-150713` 的 `restore/postgres.log`）。等到 `SELECT pg_is_in_recovery()` 返回 `f` 再让应用连这个新端口。逻辑路径是在恢复实例上建空库，再 `pg_restore --no-owner`；表计数与 dump 当时的快照一致。
 
-工件正文的库内 `content_path` 是绝对路径（`blobstore.Local.Put` 返回最终文件路径）。快照要还原到原来的目录，换目录后按库里的路径取文件会失败。2026-10-12 那次没有跑通上传：未设置 `BLOBSTORE_S3_ENDPOINT` 时，空的 `*S3` 放进对象存储接口后不再等于 nil，上传在 `blobstore.(*S3).Put` 空指针 panic，K4 记 FAIL。2026-10-13 已在 store 边界把这种带类型空指针当作未配置并回落本地目录（Backend `46073d30`）。同日在 Dev `a83588dd` 上重跑 `tests/ops/run_backup_drill.sh`，结果目录 `tests/ops/results/backup-20261013-013354`（SELF，原始结果另存于仓外 `u7-k4-retest-preserved-20261013`）。K1–K7 都过：RPO 65 秒，RTO 3 秒；K4 为 5 个工件 `checked=5`、`missing=0`、`mismatch=0`，跨用户访问项目和工件均为 404。绝对路径这一条仍然有效，快照继续还原到原目录。
+工件正文的库内 `content_path` 是绝对路径（`blobstore.Local.Put` 返回最终文件路径）。快照要还原到原来的目录，换目录后按库里的路径取文件会失败。2026-10-12 那次没有跑通上传：未设置 `BLOBSTORE_S3_ENDPOINT` 时，空的 `*S3` 放进对象存储接口后不再等于 nil，上传在 `blobstore.(*S3).Put` 空指针 panic，K4 记 FAIL。2026-10-13 已在 store 边界把这种带类型空指针当作未配置并回落本地目录（Backend `46073d30`；合入 main 的 `dc736e3` 与该提交同树）。同日在 Dev `a83588dd` 上重跑 `tests/ops/run_backup_drill.sh`，结果目录 `tests/ops/results/backup-20261013-013354`（SELF，原始结果另存于仓外 `u7-k4-retest-preserved-20261013`）。K1–K7 都过：RPO 65 秒，RTO 3 秒；K4 为 5 个工件 `checked=5`、`missing=0`、`mismatch=0`，跨用户访问项目和工件均为 404。绝对路径这一条仍然有效，快照继续还原到原目录。
 
 ### 8.7 PG / Redis 断连处置