fix: surface pgdata backup read-only blockers

TEST.md

@@ -101,6 +101,10 @@
 
 阅读 `AGENTS.md`（本项目 `AGENTS.md` 同时承担 `SKILL.md` 对 `scripts/cli.ts` 的解释职责），然后用 cli 手动测试以下内容：确认 D518 `/mnt/d/work/todo_note` 已复制到主 server `/root/todo_note`，运行 `bun scripts/cli.ts microservice list`，确认 `todo-note` 显示为 `providerId=main-server`、`public=false`、`frontendOnly=true`、仓库 URL `https://gitee.com/Lyon1998/todo_note`、`todo-note:4211` 后端映射和 `todo-note-backend` 容器摘要；运行 `bun scripts/cli.ts microservice health todo-note`，确认返回 `storage=postgres`；运行 `bun scripts/cli.ts microservice proxy todo-note /api/instances --max-body-bytes 8000`，确认能看到 `CONSTAR`、`大论文`、`找工作`、`小论文`、`事务` 五个迁移清单，总任务数不低于 100。随后通过 backend-core 或 `bun scripts/cli.ts e2e run` 执行临时清单 create/add/toggle/undo/delete 写入循环，确认 Todo Note 写入真实经过 backend-core、main-server provider-gateway、`todo-note-backend` 和主 PostgreSQL，且删除前必须按唯一临时清单名称重新选中临时清单，不能误删迁移清单。最后登录公网 frontend `http://74.48.78.17:18081/`，进入 `用户服务 / Todo Note`，确认清单、树形任务、筛选、提醒、移动、撤销/重做、字号控制都以 React 控件展示，默认没有裸 JSON，只有点击 `查看原始JSON` 才显示原始数据。
 
+## T22A PGDATA -> Baidu Netdisk 只读复核
+
+阅读 `AGENTS.md` 和 `docs/reference/deploy.md`，然后用 cli 手动测试以下内容：只运行 `bun scripts/cli.ts server status`、`bun scripts/cli.ts schedule list`、`bun scripts/cli.ts schedule runs --limit 20`、`bun scripts/cli.ts microservice status baidu-netdisk`、`bun scripts/cli.ts microservice health baidu-netdisk`、`bun scripts/cli.ts microservice proxy baidu-netdisk /api/auth/status --raw` 和 `bun scripts/cli.ts microservice proxy baidu-netdisk '/api/transfers?limit=20' --raw` 这些只读命令，确认能观察目标栈、Baidu auth health、配置存在性和最近 run/transfer 状态；不得运行 `schedule run`、`schedule retry-run`、`server start`、`server rebuild`、`deploy apply` 或 Baidu transfer POST。若 backend-core 目标容器缺失或仅有 `*.verify-*` 容器，CLI 必须非零退出并返回 `failureKind=target-stack-not-running`、`runnerDisposition=infra-blocked`、`targetStack.verifyOnlyObserved`、`readOnlyCommands` 和 `authorizationRequiredForRecovery`，而不是把空 stdout/stderr 当作通过。需要恢复时，测试记录必须先写明最小授权动作：恢复非空 Baidu Netdisk secret、启动或部署包含 backend-core/database/baidu-netdisk 的目标栈，随后再单独授权 `schedule retry-run` 或 `schedule run` 才能触发真实 PGDATA 备份。
+
 ## T23 D601 Code Queue User Service
 
 阅读 `AGENTS.md`（本项目 `AGENTS.md` 同时承担 `SKILL.md` 对 `scripts/cli.ts` 的解释职责），然后用 cli 手动测试以下内容：运行 `bun scripts/cli.ts microservice list`，确认 `code-queue-mgr` 显示为 `providerId=main-server`、`deployment.mode=internal-sidecar`、Compose 后端 `http://code-queue-mgr:4278`、`frontend.integrated=false`，并确认稳定 `code-queue` 条目说明队列管理/提交/历史/轻量 Trace 默认由主 server `code-queue-mgr` 负责，D601 k3s Code Queue 只负责 scheduler/runner/active run control 和执行态写回；使用 `bun scripts/cli.ts server rebuild code-queue-mgr` 重建主 server 控制面，再运行 `bun scripts/cli.ts microservice health code-queue-mgr`、`bun scripts/cli.ts microservice health code-queue`、`bun scripts/cli.ts microservice proxy code-queue '/api/tasks/overview?limit=5&transcriptLimit=1&compact=1&afterSeq=0&preferId='`、`bun scripts/cli.ts codex submit --dry-run --queue <queueId> <prompt>`、`bun scripts/cli.ts codex steer <runningTaskId> --prompt-stdin --dry-run` 和 `bun scripts/cli.ts codex task <已有taskId>`，确认普通控制/读取路径经 backend-core 分流到 master `code-queue-mgr`，返回 `role=master-control-plane`、`schemaReady=true`、PostgreSQL pool 上限、`noRunnerDependencies=true`、任务初始 prompt、最后 assistant message、工具调用摘要、attempt/judge/error 和耗时；`codex steer --dry-run` 必须返回 `path=/api/tasks/<runningTaskId>/steer`、`method=POST`、prompt 字符数和 `truncated=false`，且不触碰运行中 session。随后运行 `bun scripts/cli.ts codex deploy <已push的commitId>`，确认命令返回结构化错误并明确说明维护通道直连 D601 部署已禁用，且不会返回异步部署 job id；再运行 `bun scripts/cli.ts deploy apply --service code-queue --dry-run --run-now` 可只做 would-deploy 预览，去掉 `--dry-run` 时必须在运行时变更前拒绝 D601 直连部署。确认主 server 根目录 `docker-compose.yml` 中只存在 `code-queue-mgr` 而不存在执行面 `code-queue` service，并通过 `bun scripts/cli.ts ssh D601 argv bash -lc 'systemctl is-active k3s && KUBECONFIG=/etc/rancher/k3s/k3s.yaml kubectl get nodes -o wide && sudo ctr --address /run/k3s/containerd/containerd.sock -n k8s.io images ls | grep -F docker.io/rancher/mirrored-pause:3.6 && ! docker ps --format "{{.Names}} {{.Image}}" | grep -E "[[:space:]]rancher/k3s:" && ! docker ps --format "{{.Names}}" | grep -Fx code-queue-backend'` 或等价检查证明 D601 k3s 是 WSL 原生 systemd 服务、native containerd 已有正确 pause sandbox 镜像、没有 active `rancher/k3s` 控制面容器且旧 direct Docker `code-queue-backend` 没有并行运行。运行 `bun scripts/cli.ts microservice proxy k3sctl-adapter /api/control-plane --raw` 和执行面专属 `bun scripts/cli.ts microservice proxy code-queue /api/dev-ready --raw`，确认 D601 scheduler/read/write ready endpoint、`queue.storage.primary=postgres`、`queue.storage.postgresReady=true`、`queue.devReady.missingTools=[]`、`queue.devReady.docker.versionOk=true`、`queue.devReady.docker.composeOk=true`；`queue.devReady.ssh.ready` 只在需要跨 Provider SSH/Windows-native 任务时作为强制项。在 D601 active Code Queue Pod 内验证主 PostgreSQL 端口映射可执行 `select 1`，主 OA Event Flow 端口映射 `/health` 可访问，集群内 ClaudeQQ Service `http://claudeqq.unidesk.svc.cluster.local:3290/health` 可访问；这些映射不得成为任意公网入口。