feat: 主线 /goal 命令自动建 goal

发给主线的一句话（含字面 /goal）即可自动建 goal，不用先
知道主线是进行中还是已终态，也不用勾选项：
- cloud/goal_command.py：server 与 worker 共用的纯文本解析，
  只认命令形状（/goal 开头、分隔符/目标标记、开启类动词），
  讨论里提到 /goal 不误触发；空目标返回空串供调用方 400。
- server followup/thread/message/continue 三入口同款：queued
  原地转 goal，已终态复活并转 goal，running 排队后由 worker
  在轮次边界转 goal；已是 goal 409、plan 400、merged 409。
- worker 排空：/goal 不当普通轮次跑，CAS 把 running 主线
  改回 queued 并写 goal/resume_message，下次认领走 goal-resume
  在同一 thread 上开新目标循环；取消/回收时 CAS 失败则把
  followup 放回 pending，绝不把取消过的任务改回 queued。
- 单测 14 项：解析、三态转换、拒绝口径、普通消息不受影响、
  continue/thread 同款、worker 轮次边界转换 + 下次 goal 跑通。

cloud/README.md

@@ -532,6 +532,27 @@ goal 模式的继续：server 把任务转成新 goal 语义（goal=新消息、
 合并任务 worktree 已删、请分支（merged 409）；冲突与新建一致
 （plan + approval=full、plan + goal 各 400）。
 
+## 主线 /goal 命令（发给主线一句话就自动建 goal）
+
+不用先知道主线是进行中还是已终态，也不用勾选项：给主线发
+一条含字面 `/goal` 的消息即可，例如“请在这条主线开启一个
+持久 /goal，目标是收xxx”，或直接写“/goal 收xxx”。解析在
+`cloud/goal_command.py`（server 与 worker 共用同一份，防两端
+判断不一致）；只是在讨论里提到“/goal 的用法”不算命令。
+入口三处同款：`POST /tasks/{id}/followups`、
+`POST /tasks/{id}/thread/message`、`POST /tasks/{id}/continue`
+（message 字段）；响应里 `delivery` 说明实际走了哪条路：
+queued 主线原地转 goal（`goal_converted`）、已终态复活并转
+goal（`goal_revived`）、running 主线先排队（`goal_queued`，
+本轮不打断，worker 在本轮完成、排空到这条时把主线转成 goal
+并回 queued，下次认领走 goal-resume 在同一 thread 上开新
+目标循环；本轮若失败，这条留在 pending，等下次成功轮次再转）。
+拒绝口径：已是 goal 任务 409（不重复创建）、plan 任务 400、
+merged 409、空目标 400。goal 语义与新建 goal 模式一致：
+不限轮次、模型宣告“目标已达成”才结束，宣告后即终态，不
+是永不结束的常驻采集——需要继续收时再发一次 /goal 续开
+新循环。
+
 ## 任务间互发消息（peer messages，Muse 式通用互发）
 
 任意两个同项目任务可以互发消息、对方做完可以回消息，不