feat: run confirmed proposals continuously until a real decision point

A proposal still needs one confirmation before it starts, but once it is
working the worker now treats that as a single grant to carry out
routine low-risk execution without step-by-step reconfirmation. It only
returns pending early for high-risk actions, key business decisions,
external blockers, or dirty/unexpected targets. Assistant/worker
bootstrap copy and docs now align with that execution model.

README.md

@@ -196,7 +196,7 @@ QQ 出站图片：Worker/Assistant 报告的 workspace 内图片（png/jpg、≤
 运行链路是三层：
 
 - **Assistant**：每个 conversation（chat + user）一个无工具 ACP 会话，只与用户对话；同群不同用户的会话互相隔离。它把用户意图整理成 Proposal（title、goal、steps），并解释 Worker 的反馈。Assistant 每条回复必须以隐藏 `GORI_ASSISTANT_ACTION_V2` envelope 结尾（`reply` + `actions`），action 只有 `create_proposal`、`confirm`、`adjust_proposal`、`follow_up`、`finish`、`send_image`、`start_next`、`cancel`、`stop`；格式错误只修复一次（envelope 缺闭合标签时先按花括号配平 salvage，失败才修复）。`send_image { path }` 把 Worker 报告过的 workspace 内图片发给用户，与 Worker 附件同样的路径/类型/大小校验。
-- **Proposal**：一份工作单，owner 是 chat + 发起用户；`confirm` / `adjust` / `follow_up` / `start_next` 仍只有发起人本人可操作（runtime 强校验），但为了避免单人把单 worker 队列卡死，`finish` / `stop` / `cancel` 是全板共享动作：任何用户都可对可见 proposal 执行它们。Proposal 板全局共享可见：Assistant prompt 的全板列表包含所有 chat/user 的未完成条目（自己的标 `scope=own`，他人的标 `scope=other` 并附 chat 类型，不暴露 openid 明文），Assistant 可如实向任何用户描述全板状态。状态流为 `proposed → queued → working → pending → finished`。`proposed` 只有用户确认后才进入 `queued`；`pending` 就是「等用户决定」，不再区分 success/failure；只有 `finish` 把 pending 落定为 `finished(done)`，`cancel` 落定为 `finished(cancelled)`。
+- **Proposal**：一份工作单，owner 是 chat + 发起用户；`confirm` / `adjust` / `follow_up` / `start_next` 仍只有发起人本人可操作（runtime 强校验），但为了避免单人把单 worker 队列卡死，`finish` / `stop` / `cancel` 是全板共享动作：任何用户都可对可见 proposal 执行它们。Proposal 板全局共享可见：Assistant prompt 的全板列表包含所有 chat/user 的未完成条目（自己的标 `scope=own`，他人的标 `scope=other` 并附 chat 类型，不暴露 openid 明文），Assistant 可如实向任何用户描述全板状态。状态流为 `proposed → queued → working → pending → finished`。`proposed` 只有用户确认后才进入 `queued`；proposal 一旦进入 `working`，worker 默认连续执行普通低风险步骤，不再逐步回问，只有碰到高风险动作、关键业务选择、外部阻塞或 dirty/异常目标时才返回 `pending question`；`pending` 就是「等用户决定」，不再区分 success/failure；只有 `finish` 把 pending 落定为 `finished(done)`，`cancel` 落定为 `finished(cancelled)`。
 - **Worker**：同一时刻全实例只有一个，在 `bot.workspace` 用 `bot.permissions` policy 执行一个已确认 Proposal。每轮必须以隐藏 `GORI_WORKER_RESULT_V2` envelope 收尾：`PENDING`（`summary` 必填，可带 `question`、`workspaceDirty`），不区分成功/失败，只把结果交给用户。Worker 给用户看的图片（png/jpg）必须保存在 workspace 内（建议 `.gori-outbox/`），并通过 `attachments: [{ path, mimeType? }]`（最多 3 个）上报；runtime 校验路径必须在 workspace 内、magic bytes 为 png/jpg、单张 ≤10MB，违规的丢弃并在事件文本里说明。
 
 确认语义是刻意的：