fix: add Code Queue steer confirmation

docs/reference/code-queue-supervision.md

@@ -337,7 +337,10 @@ D601 artifact registry 的 systemd unit inactive 不等于 D601 全局离线。
 只有存在明确理由时才干预。
 
 - 如果任务还在运行且 trace 或 scheduler heartbeat 新鲜，应引导而不是 interrupt。
-- 对运行中任务的引导应优先使用正式 CLI：`bun scripts/cli.ts codex steer <taskId> --prompt-file <path>`。该命令和 `codex task/tasks/read` 复用同一个 backend-core stable proxy helper；`--dry-run` 会显示 `method/path/stableProxyPath`、retry policy、prompt 摘要和 raw proxy 等价命令但不发送。非 dry-run 默认对 `stable-proxy-failed` 和 `backend-core-unreachable` 做一次有界重试，失败时先看 `.data.diagnostics.reason`、`.data.diagnostics.attempts` 和 `.data.diagnostics.operatorGuidance`：`backend-core-unreachable` 属于本机到 core 的观察路径，`code-queue-microservice-unregistered`/`proxy-unauthorized`/`proxy-404` 属于 stable proxy 配置或权限，`steer-endpoint-404`/`upstream-runtime-rejected` 属于 D601 runtime 或任务状态，`stable-proxy-failed` 多为 provider/k3s/tunnel 链路问题。默认失败输出必须保持低噪声：不回显 steer prompt、不带 request body、不带 upstream body preview，也不带 raw response；需要上游预览或原始失败对象时显式重跑 `--full` 或 `--raw`。`502 provider HTTP tunnel failed`、`The operation was aborted`、约 30 秒 provider tunnel wait abort 仍失败时，`.data.steer.deliveryUnconfirmed=true`；指挥官应先用 `codex tasks --view supervisor --limit 20`、`codex task <taskId>` 和 `microservice health code-queue` 交叉确认任务活性，再从主 server CLI 或显式 SSH transport 重试同一个 steer。raw proxy 等价命令走同一条 tunnel，`rawProxyEquivalentIsFallback=false`，只能做诊断对照，不应作为正式 fallback。若任务已终态，CLI 返回紧凑 `task-already-terminal` 响应并给出 `bun scripts/cli.ts codex task <taskId>`、`bun scripts/cli.ts codex read <taskId>` 和 `bun scripts/cli.ts codex submit --prompt-file <path> --reference-task-id <taskId>`；指挥官应提交 follow-up task，而不是继续 steer 终态任务。若正式 CLI 自身不可用，临时通过受控 microservice proxy 调用只能作为现场恢复手段；这类绕行必须记录到指挥简报 issue #24 主体的常驻观察，并创建正式 issue 补齐 CLI 能力，避免长期依赖隐式 API。
+- 对运行中任务的引导应优先使用正式 CLI：`bun scripts/cli.ts codex steer <taskId> --prompt-file <path>`。该命令和 `codex task/tasks/read` 复用同一个 backend-core stable proxy helper；`--dry-run` 会显示 `method/path/stableProxyPath`、`steerId`、retry policy、prompt 摘要、`commands.traceConfirm` 和 raw proxy 等价命令但不发送。非 dry-run 默认对 `stable-proxy-failed` 和 `backend-core-unreachable` 做一次有界重试，且每次 retry 都复用同一个 `steerId`；后端按同 `steerId`+同 prompt 抑制重复 trace 注入，返回 `duplicateSuppressed=true`，同 `steerId` 搭配不同 prompt 返回 conflict。
+- 真实 steer 输出必须保持低噪声：成功显示 `steer.status`、`steer.deliveryState`、`steer.steerId`、有界 `traceConfirmation` 和后续命令，不回显 prompt 或完整 task state；失败默认不带 request body、不带 upstream body preview，也不带 raw response，需要上游预览或原始失败对象时显式重跑 `--full` 或 `--raw`。`deliveryState=accepted` 表示 backend 已接受；`not_accepted` 表示任务状态/权限/输入未接受；`accepted_response_timeout` 表示 stable proxy 响应超时但 trace confirmation 找到该 `steerId`；`unknown` 表示响应路径失败且确认查询仍未证明接受。
+- `502 provider HTTP tunnel failed`、`The operation was aborted`、约 30 秒 provider tunnel wait abort 仍失败时，先看 `.data.diagnostics.reason`、`.data.diagnostics.attempts`、`.data.traceConfirmation` 和 `.data.commands.traceConfirm`。若 `.data.steer.deliveryUnconfirmed=true`，不要立刻复制同一纠偏 prompt 再发；先运行 `bun scripts/cli.ts codex steer-confirm <taskId> --steer-id <id>`。如果确认 accepted 或 accepted_response_timeout，停止重发并继续观察 `codex task <taskId>` / `codex task <taskId> --trace --tail --limit 80`；如果仍 unknown，再用输出中的 retry 命令复用同一个 `--steer-id`。raw proxy 等价命令走同一条 tunnel，`rawProxyEquivalentIsFallback=false`，只能做诊断对照，不应作为正式 fallback。
+- 失败分流仍以 `.data.diagnostics.reason` 为准：`backend-core-unreachable` 属于本机到 core 的观察路径，`code-queue-microservice-unregistered`/`proxy-unauthorized`/`proxy-404` 属于 stable proxy 配置或权限，`steer-endpoint-404`/`upstream-runtime-rejected` 属于 D601 runtime 或任务状态，`stable-proxy-failed` 多为 provider/k3s/tunnel 链路问题。若任务已终态，CLI 返回紧凑 `task-already-terminal` 响应并给出 `bun scripts/cli.ts codex task <taskId>`、`bun scripts/cli.ts codex read <taskId>` 和 `bun scripts/cli.ts codex submit --prompt-file <path> --reference-task-id <taskId>`；指挥官应提交 follow-up task，而不是继续 steer 终态任务。若正式 CLI 自身不可用，临时通过受控 microservice proxy 调用只能作为现场恢复手段；这类绕行必须记录到指挥简报 issue #24 主体的常驻观察，并创建正式 issue 补齐 CLI 能力，避免长期依赖隐式 API。
 - 如果任务进入终态但缺少必要验收证据，应使用聚焦 continuation prompt retry 同一任务。
 - 如果任务被可复用基础设施缺陷阻塞，应把该缺陷分配给合适的空闲或低风险队列，让原业务任务等待，或在修复后 retry。
 - 如果基础设施缺陷影响 Code Queue 控制面可用性，指挥官可以执行恢复队列所需的最小受控部署，然后验证原任务能继续。