fix(commondev): 投递任务改成真异步，不再同步等 pi 跑完

## 缺陷（用户质疑"投递不就是发一条消息"后实测确认）

`deliverToPi` 的注释写着"把给 pi 发消息包装一下"，但实际是：

	await s.prompt(text)   // 同步等 pi 把**整个任务**跑完

而 pi/zcode 开工程线干活（克隆/改代码/跑测试）要几十秒到 20 分钟。
生产日志实测两次：

	23:04:03  executing tool: output_send__commondev_br-...
	23:05:03  ★ timed out after 60s

通道的语义是"**投递**任务"（见 outputch 描述），不是"等完成"。
把它实现成同步等待，就必然撞上内核的 60s 工具超时。

★ 我一开始的诊断是错的：以为"超时值太小"，给 output_send 声明了 3m
  —— 那是掩盖症状。投递本该瞬时返回，慢是 bug 不是需求。已撤回。

## 改动

	投递 → 立即回 status=accepted（瞬时）
	     → pi 在后台跑
	     → 跑完推**主动通知**（id=0）
	     → Go 侧 onNotify 经 inputch 注入回 agent

`sidecar.go` 的 readLoop 里早就留好了这个扩展位：
    if resp.ID == 0 { // 主动通知（暂未使用，保留扩展位）
现在接上了 `makePromptNotifier`。

pi 与 zcode 两份 sidecar.mjs 都改了（rawfile/ 里那两份同步更新）。

## 判据抓到我三次（都是真问题）

1. `TestSidecarScriptShipsWithPackage`：rawfile/ 与工程根不一致
   —— 我只改了根那份
2. `TestZcodeMissingCLIErrorIsActionable`：`inflight is not defined`
   —— zcode 版用了未声明变量
3. 同一条判据随后**卡死 2 分钟**：CLI 不存在本该立刻报，异步后错误
   被吞进后台通知 ⇒ 用户先收到"已受理"、几秒后才知道配置错。
   改成**受理阶段就校验 CLI**（配置错是立刻可判定的，不该推迟）。

判据还逼我保住语义：原 `TestZcodeSidecarArgvBehavior` 断言首轮拿到
真实 `sess_` id，异步后要到完成通知里才有 —— 断言保留、改从通知取，
没有削弱。

## 真机 e2e（三条全过，都要求真改工程文件）

	TestZcodeFullPipeline              42.1s
	TestZcodeOverSSH                   72.4s
	TestZcodeOverSSHWithPerHostEndpoints 75.1s

受理现在是瞬时的 ⇒ 内核工具不会再 60s 超时。

example/commondev/ssh_wiring_test.go

@@ -509,6 +509,26 @@ process.stdout.write(JSON.stringify({type:"result",sessionId:sid,response:"ok"})
 		return nil
 	}
 
+	// readNotification 读一条**主动通知**（id=0）。
+	//
+	// 异步投递后，任务完成不是通过请求应答返回，而是 sidecar 主动推一帧
+	// id=0 的通知（见 sidecar.go readLoop 的分派）。
+	readNotification := func(t *testing.T) map[string]any {
+		t.Helper()
+		for sc.Scan() {
+			var m map[string]any
+			if json.Unmarshal(sc.Bytes(), &m) != nil {
+				continue
+			}
+			if id, _ := m["id"].(float64); id == 0 {
+				res, _ := m["result"].(map[string]any)
+				return res
+			}
+		}
+		t.Fatal("等完成通知超时")
+		return nil
+	}
+
 	// 首轮
 	mustWrite(map[string]any{"jsonrpc": "2.0", "id": 1, "method": "prompt",
 		"params": map[string]any{"session_id": "br-demo-label", "text": "hi"}})
@@ -517,10 +537,24 @@ process.stdout.write(JSON.stringify({type:"result",sessionId:sid,response:"ok"})
 		t.Fatalf("首轮失败: %v", r1["error"])
 	}
 	res1, _ := r1["result"].(map[string]any)
-	sid, _ := res1["session_id"].(string)
-	if !strings.HasPrefix(sid, "sess_") {
-		t.Fatalf("★ 首轮未回报真实 sess_ id: %q", sid)
+	// ★ 异步投递（2026-10-17）：prompt 立即回 "accepted"，此时**还拿不到**
+	// 真实 sess_ id（它要等 zcode 真正建好会话）。真实 id 随完成通知推回。
+	// 首轮这里只要求"受理成功且回报了一个 session_id 字段"。
+	if st, _ := res1["status"].(string); st != "accepted" {
+		t.Fatalf("首轮应回 status=accepted（异步投递），实际 %q", st)
 	}
+	sid, _ := res1["session_id"].(string)
+	if sid == "" {
+		t.Fatal("★ 首轮未回报 session_id 字段（Go 侧据此断言会话未漂移）")
+	}
+
+	// 等完成通知（id=0），从里面取真实 sess_ id
+	notif := readNotification(t)
+	realSid, _ := notif["session_id"].(string)
+	if !strings.HasPrefix(realSid, "sess_") {
+		t.Fatalf("★ 完成通知里未含真实 sess_ id: %q（通知=%v）", realSid, notif)
+	}
+	sid = realSid
 
 	// 第二轮：把真实 id 传回 → 必须 --resume
 	mustWrite(map[string]any{"jsonrpc": "2.0", "id": 2, "method": "prompt",
@@ -528,6 +562,9 @@ process.stdout.write(JSON.stringify({type:"result",sessionId:sid,response:"ok"})
 	if r2 := readReply(2); r2["error"] != nil {
 		t.Fatalf("第二轮失败: %v", r2["error"])
 	}
+	// 第二轮同样是异步：应答只代表"已受理"，假 CLI 的第二次执行发生在
+	// 完成通知之前。必须等通知，否则读 argv 时第二次还没被调起（实测）。
+	_ = readNotification(t)
 
 	raw, err := os.ReadFile(rec)
 	if err != nil {