fix(commondev): 完成通知回填投递台账（原先永远停在 accepted）

## 缺陷（2026-10-18 本机实例日志实测）

异步投递上线后，台账里的记录全是 accepted、result 永远为空：

	07:39:09 accepted result=None
	07:40:09 accepted result=None
	07:41:18 accepted result=None     ← 13 条全是

而回投本身**是正常的**（[plugin] 日志有 5 次 `回投任务结果…event=prompt_done`）。
缺的是：完成通知到达后没人把它写回台账。

实测后果（同一天日志，agent 自己起的轮询）：

	[timer] firing: 【轮询轮次 2/6】…检查是否有新 result 回填…

agent 为此安排了 6 轮 timer 去等一个**永远不会出现**的回填，白等 30 分钟。
更根本的是：看板与任何查询方都拿不到任务结果。

## 修法

`completeDelivery`：把完成/失败结果回填到该 branch 下**最新一条**
未回填的 accepted。`recordDelivery` 改为返回 key（追溯用）。

匹配用"最新未完成"而不是按 key：完成通知里没有 key（sidecar 不知道它），
而同一 branch 的投递是串行投给同一个 pi 会话的，最新未完成那条就是它。

## 判据（6 条）

回填最新 / 不串 branch / 不覆盖已回填 / 无匹配不 panic / 返回 key /
**完成通知真的调用了回填**（接线判据）

## ★ 写判据时踩的两个坑（都记在注释里）

1. **判据没覆盖接线 → 变异不咬**：前 5 条测的是 completeDelivery 自身行为。
   把 sidecar.go 里**那一行调用删掉**，它们依然全绿 —— 而"函数写得对但
   没人调"正是原始缺陷的形态。补了第 6 条读源码验接线。

2. **偏移错位导致假绿**：分段用 `seg := block[k:]` 后找 "case "，会命中
   k 自己（n=0）⇒ seg 不截断、含整个函数剩余部分 ⇒ done 分支删掉回填也照样
   "找到" error 分支那一行。改成跳过 `case "x":` 本身的长度再找。

example/commondev/plugin.go

@@ -1380,11 +1380,13 @@ func (p *Plugin) deliverToPi(branchID string, cargs map[string]interface{}) (int
 	}, nil
 }
 
-func (p *Plugin) recordDelivery(branchID, sessionID, text, status, note string) {
+// recordDelivery 记一条投递台账，返回它的 key（供完成时回填）。
+func (p *Plugin) recordDelivery(branchID, sessionID, text, status, note string) string {
 	p.mu.Lock()
 	defer p.mu.Unlock()
+	key := fmt.Sprintf("%s-%d", branchID, time.Now().UnixNano())
 	p.ledger.Deliveries = append(p.ledger.Deliveries, Delivery{
-		Key:      fmt.Sprintf("%s-%d", branchID, time.Now().UnixNano()),
+		Key:      key,
 		BranchID: branchID, Text: truncate(text, 200),
 		SessionID: sessionID, Status: status, Result: note,
 		At: time.Now().Format(time.RFC3339),
@@ -1394,6 +1396,43 @@ func (p *Plugin) recordDelivery(branchID, sessionID, text, status, note string)
 		p.ledger.Deliveries = p.ledger.Deliveries[n-200:]
 	}
 	_ = p.saveLocked()
+	return key
+}
+
+// completeDelivery 把完成/失败结果**回填**到某条投递台账。
+//
+// ★ 为什么必须有它（2026-10-17 生产实测缺陷）：
+//
+//	异步投递后，投递那一刻只能记 "accepted"；真正的结果几十秒后才由
+//	完成通知送回来。原先没人把它写回台账 ⇒ 台账永远停在 accepted，
+//	看板/agent 都**查不到任何结果**。
+//	实测后果：agent 自己起了一个 6 轮的 timer 去轮询"有没新 result 回填"，
+//	而那件事永远不会发生 —— 白等 30 分钟。
+//
+// 匹配策略：找该 branch 下**最新一条**尚未回填（Result 为空）的 accepted。
+// 不做"按 key 精确匹配"是因为完成通知里没有 key（sidecar 不知道它）——
+// 而同一 branch 的投递是串行投给同一个 pi 会话的，最新未完成那条就是它。
+func (p *Plugin) completeDelivery(branchID, sessionID, status, result string) {
+	p.mu.Lock()
+	defer p.mu.Unlock()
+	for i := len(p.ledger.Deliveries) - 1; i >= 0; i-- {
+		d := &p.ledger.Deliveries[i]
+		if d.BranchID != branchID || d.Result != "" {
+			continue
+		}
+		if d.Status != "accepted" {
+			continue
+		}
+		d.Status = status
+		d.Result = truncate(result, 500)
+		if sessionID != "" {
+			d.SessionID = sessionID
+		}
+		_ = p.saveLocked()
+		log.Printf("[commondev] 台账回填：%s → %s", d.Key, status)
+		return
+	}
+	log.Printf("[commondev] 台账回填：branch=%s 没有待完成的 accepted 记录（通知可能早于投递落盘）", branchID)
 }
 
 func (p *Plugin) handleBranchStatus(args map[string]interface{}) (interface{}, error) {