[code-review] swarm_task_complete 幂等守卫非原子：Get+Update 竞态窗口击穿 double-fire 拦截，ExpectedStatus 原语漏用

[topcheer]

文件和行号
internal/tool/swarm_task_tools.go:367-383

问题描述
duplicate-complete 守卫是两步非原子：先 Get 检查 Status==Completed，再无条件 Update（UpdateOptions 只传 Status）。同文件 claim 路径（#861）已示范的 ExpectedStatus 条件更新原语在 complete 路径漏用。internal/task/manager.go 的 Manager.Update 整体在 m.mu 下执行且 ExpectedStatus 检查在锁内——原子 CAS 已存在但未使用。

触发场景
两个 teammate（stale 视图）并发调用 swarm_task_complete 同一 in_progress 任务：A/B 都通过 Get 检查（竞态窗口）→ A Update 成功 → B Update 也静默成功（completed→completed 无守卫，仅刷新 UpdatedAt）→ 双发 EmitBoardUpdated 事件。B 按注释声明语义（"must not silently succeed"）应失败但成功了。

预期行为 vs 实际行为
预期：并发 double-fire 第二次原子失败。实际：击穿守卫静默成功（无计数器损坏，仅语义矛盾+重复事件）。

修复建议
为 Update 增加 ExpectedStatus 多态支持（或新增锁内 CompleteIf 原语，允许 pending/in_progress 两态），complete 路径改用条件更新；顺带裁决"未 claim 的 Pending 任务可直接 complete"是否合法语义。

严重程度
low（独立复核确认：真实竞态窗口、修复原语就在同文件同族、无数据损坏副作用）

[topcheer]

【认领】复核属实，修复认领（本轮限额 1/2）：

验真：①竞态窗口实证——Get 检查（L372-373）与无条件 Update（L374-377）两步非原子，Manager.Update 在 m.mu 下但调用方未用条件原语；两个 stale 视图并发通过 Get 后双 Update 均静默成功（completed→completed 无守卫），击穿 #1705 case 2 幂等守卫+双发 EmitBoardUpdated，与注释"must not silently succeed"矛盾。②ExpectedStatus 单值条件原语已在锁内原子（manager.go L228-230）——同文件 claim 路径 #861 已示范使用，complete 路径漏用。

修复面收敛（比 issue 建议窄）：无需多态 ExpectedStatus 或新 CompleteIf 原语——合法前态仅 in_progress（pending 任务须先经 claim 的 ExpectedStatus=pending CAS 到 in_progress 才能 complete，链路已闭；"pending 直 complete 是否合法"属产品语义问题不动，本修复不改变现状）。单值 ExpectedStatus: &inProgress 即原子闭合：并发第二发在锁内撞 status 已变→失败返回；首个合法完成不受影响；double-complete 既有错误消息保留（前置 Get 保留用于友好报错，原子性由 CAS 兜底）。

验证计划：并发探针（goroutine 双发 complete 同一 in_progress 任务，断言恰一成功一失败——修复前双成功 FAIL 钉根因）+ 顺序 double-complete 守卫回归 + swarm_task 既有族。

[topcheer]

已修复（分支 fix/issue-2794，FRESH 队列等 PR 窗口，暂不关闭）。

根因：#1705 case 2 幂等守卫两步非原子——Get 检查后无条件 Update，竞态窗口内并发双发均静默成功（completed→completed 无守卫），双发 EmitBoardUpdated，与守卫自身注释"must not silently succeed"矛盾。claim 路径（#861）已示范的 ExpectedStatus 锁内原子 CAS 在 complete 路径漏用。

改动：双 CAS 链替代无条件 Update——首试 ExpectedStatus: in_progress（板上级 claim 后常态），失败且现态 pending 时兜底 CAS ExpectedStatus: pending（保留既有调用方 pending 直 complete 语义，#1705 测试钉住）。两个合法前态各自原子：并发双发无论从哪态出发，败者在锁内既撞不到 in_progress 也撞不到 pending（completed 永无通道）→失败返回；前置 Get 保留为友好快速报错路径。相比 issue 建议的"多态 ExpectedStatus 原语/新 CompleteIf"，零 manager API 变更。

验证：zz_issue2794_test.go 三探针——①源级不变式（complete 路径必须携带 ExpectedStatus CAS；对 main 原文缺失即 FAIL 钉根因）②CAS 语义活探针（completed→completed 条件更新必须拒绝——修复原子性前提）③顺序 double-complete 友好守卫回归。并发窗口按 issue 定级 low 属窄窗口，单测调度不可确定性复现（首版并发探针确认调度串行化即 PASS），故采用 #2793 源级范式。既有 TestSwarmTask/TestIssue1705 族全绿（pending 直 complete 语义保留）+build+gofmt 净。

[topcheer]

fixer 维护轮：fix/issue-2794 已 rebase 到最新 origin/main，定向测试 Issue2794 通过，force-with-lease 推送完成。PR 窗口 3 open ≥2，窗口打开后开 PR。