fix(bridges): 续谈失败静默 + duplicate_relay 静默挂死（两个都是「人那边什么都收不到」）

同一类问题在两个地方：出事的当下看不出来，表现是「信发出去了，然后再无音讯」。

## 1）pi 的续谈失败不回失败信（实测缺口）

模型侧 402（余额不足）时，**新会话**那条路会回一封「处理失败」，而**续谈**那条路
只写日志就 `throw` —— 发件人什么都收不到。邮件驱动的会话没有本地界面可以看，
没有这封信就等于静默挂死。复现条件很普通：往一条**已存在**的会话再发一封信。

修法与邻居一致：续谈失败也回失败信。但**不能复用**共用库的 `renderFailureReport`
——那段文案说「划定范围内的模型全部调用失败」并建议「调整可用模型范围」，
而续谈是**故意不降级**的（换模型＝换会话＝丢掉上下文，而上下文正是发件人指定
这条会话的原因）。照抄等于让人去调一个在这里无效的旋钮，他会去改配置，
然后发现依然失败。新增 `renderResumeFailure`：点明是续谈、附上游错误原文、
建议「确实要换模型就新建一条会话」。

**活体验证**（模型侧仍是 402，失败本身就是测试条件）：发一封进 pi 的已有会话，
5 秒内收到失败信，内容含 402 原文且不再出现「调整模型范围」。

顺带把 pi 里 2 处没 clamp 的 relay_key 收敛（上一轮审计只看了权限键）。

## 2）duplicate_relay：只有 zcode 认，另三桥会等一个永远不会来的决策

网关对重复的 relay_key 回 **HTTP 200 `{status:"duplicate_relay"}` 并提前返回**：
不建请求、不发邮件、**永远不会有人来决策**。zcode 桥认它并当场失败，而
pi/opencode/dsh 把它当成功，接着等 `permission_decision` 事件 —— pi 那句
`await new Promise(...)` 连超时都没有。这是 zcode 上一轮那个缺陷的同类，
只是发生在另三个桥上。

- `lib/relay-key.js`（**共用**，四处逐字节同源）新增 `isDuplicateRelay` /
  `DUPLICATE_RELAY_STATUS`：它长得像成功（200），所以必须单独认；对「发信」
  那一侧重复就该当成功（幂等），但对「等一个决定」那一侧它与故障后果相同。
- pi / opencode / dsh 三桥在权限转发处接上判据并**当场拒绝**
  （各自用自己的拒绝形状：`block: true` / `output.status = "deny"` / `'rejected'`）。
- zcode 里那份本地实现收敛到共用库（同一判据不该有两个定义）。

## 3）新增接线断言（带判据自检）

`test/permission-forward-wiring.test.mjs`（pi/opencode/dsh 三份同一内容）：
纯函数测试对这类缺口天生无能为力（函数是对的，只是没人调用它），所以它读源码
验形态，钉住「判据在、落在权限转发这条路上、给出本桥形状的拒绝」。

三条自检都在写的过程中抓到了我自己的错：
- 第一次 `ROOT` 算错 → 过滤后 0 个桥、循环全不跑而「全绿」→ 加了
  「找不到装着各桥的目录就判红」；
- 顺序判据写成「在文件里最早的 await 之前」，量到了别处的等待 → 三桥全红，
  改成「必须在上报之后」；
- dsh 是**两段式**（`.then` 里抛、`catch` 的 `duplicateRelay` 分支里拒），
  第一版抽取套错了分支 → 永远找不到 `return 'rejected'`。
扰动验证：把 pi 的判据禁用后该条变红，还原即绿（改动前后都核对了字节数）。

而 dsh 那条也暴露了：我把返回形状写成了 opencode 的 `{status:'deny'}`，
**`tsc` 没报错**（返回类型是宽联合），只有对着邻居读才发现 DSH 要的是
`'rejected'` 字符串 + `noteDenial`。

## 4）部署脚本：zcode 分支现在会重启驱动

`redeploy-plugin.sh` 的 zcode 分支只切软链（宿主是 ZCode 应用，不能重启它），
但**驱动是我们自己的 unit** —— 不重启它，进程里跑的还是切换前的代码。
这个由刚写的 `check-deploy-drift.mjs` 当场抓到（它比进程启动时刻与软链切换时刻），
而当时所有其它检查都是绿的。已补上重启并验证。

## 复查

四桥全量 413 / 321 / 370 / 380 全绿；共用库四方同源；部署漂移四项全通过；
四桥真发真收冒烟（dsh/opencode/zcode 正常回信；pi 因模型侧 402 回失败信 ——
这正是上面第 1 条要修的路径）。

另：写这段时踩到一个自伤 —— 用 `npx asar extract-file <asar> dist/index.html`
检查包内容时，它把文件**写进了 cwd**，正好覆盖掉 Vite 的源码模板
`client/electron/index.html`（下次构建会拿被污染的模板去构建）。已还原并重建，
产物哈希与之前一致。要看 asar 内容请用 `@electron/asar` 的 API（返回 Buffer），
别用这个 CLI 子命令。

plugins/zcode-mail-bridge/lib/approval.mjs

@@ -38,7 +38,7 @@
 
 import { createSSEClient } from './sse-client.js';
 import { randomUUID } from 'node:crypto';
-import { clampRelayKey, isPermanentFailure } from './relay-key.js';
+import { clampRelayKey, isPermanentFailure, isDuplicateRelay } from './relay-key.js';
 import { isApproval, isAlwaysDecision } from './permission-grants.js';
 import { normalizeMode, DEFAULT_MODE, MODE_FULL, MODE_PLAN } from './permission-mode.js';
 /** 等待人工决策的默认上限。调用方应保证它**明显小于**自己的杀进程上限，
@@ -95,10 +95,9 @@ export function relayKeyForCall({ seed, sessionId, toolName, nonce }) {
   return clampRelayKey(`${head}:${tail}`);
 }
 
-/** 网关在幂等命中时的回包形状（实测）：建请求被跳过，不会有任何人来决策。 */
-export function isDuplicateRelay(res) {
-  return Boolean(res && typeof res === 'object' && res.status === 'duplicate_relay');
-}
+// `isDuplicateRelay` 与 `DUPLICATE_RELAY_STATUS` 已挪到 **共用库** `lib/relay-key.js`：
+// 四个桥都要认这个回包，各写一份必然分叉（而这个判据是「静默挂死」与
+// 「当场拒绝」的分界）。这里只 import。
 
 /**
  * 询问人类。

plugins/zcode-mail-bridge/lib/relay-key.js

@@ -125,3 +125,41 @@ export function isPermanentFailure(err) {
   if (status === 408 || status === 429) return false;        // 超时 / 限流 → 暂时
   return status >= 400 && status < 500;
 }
+
+/**
+ * 网关把重复的 relay_key 判为**幂等命中**时的回包标识。
+ *
+ * 两个出口都会这么答（权限询问与代发邮件），且都是 **HTTP 200 且提前返回**：
+ * 不建请求、不发邮件，**也永远不会有人来决策**。
+ */
+export const DUPLICATE_RELAY_STATUS = 'duplicate_relay';
+
+/**
+ * 这个回包是不是「重复键，什么都没发生」。
+ *
+ * ## 为什么必须单独认它
+ *
+ * 它长得像成功（200），所以「发完就等决策」的实现会一直等下去。实测过的形态：
+ * pi 的 worker 在 `post('/permission/request')` 之后无条件
+ * `await new Promise(resolve => pending.set(relayKey, resolve))`，而那个 resolve
+ * 只由 `permission_decision` 事件触发 —— 重复的键永远不会带来决策，
+ * 于是那封邮件**静默挂死**（模型干等，人以为在跑）。
+ *
+ * 什么时候会重复（都是**正常**的重试，不是故障）：
+ *
+ *   - 插件重启后重放同一轮（键是确定性的，这正是它的设计目的）
+ *   - SDK / 上游重放同一个 tool call
+ *   - 上一次询问已经被人决定过，而这一侧没收到那个决策（重启、断线）
+ *
+ * 对「发信」那一侧，重复就该当成功（幂等，这正是网关返回 200 的意思）；
+ * 但对「等一个决定」那一侧，它与故障的后果完全一样：永远等不到。
+ * 所以两边的处置必须分开写，而不是共用一个「发成功了」的判定。
+ *
+ * @param {unknown} res 网关的响应体（不是 HTTP 响应对象）
+ * @returns {boolean}
+ */
+export function isDuplicateRelay(res) {
+  return Boolean(
+    res && typeof res === 'object' && !Array.isArray(res) && res.status === DUPLICATE_RELAY_STATUS
+  );
+}

plugins/zcode-mail-bridge/test/relay-key.test.mjs

@@ -21,6 +21,8 @@ import {
   truncateToBytes,
   clampRelayKey,
   isPermanentFailure,
+  isDuplicateRelay,
+  DUPLICATE_RELAY_STATUS,
 } from '../lib/relay-key.js';
 
 // ─── byteLength ───
@@ -192,3 +194,42 @@ test('2xx / 3xx 不算永久失败（本不该走到这里，但不能误判成
   assert.equal(isPermanentFailure({ status: 200 }), false);
   assert.equal(isPermanentFailure({ status: 302 }), false);
 });
+
+// ─── isDuplicateRelay ─────────────────────────────────────────────────────
+//
+// 这一组来自一个**静默挂死**：网关对重复的 relay_key 返回 HTTP 200 +
+// `{status:"duplicate_relay"}` 并提前返回（不建请求、不发邮件、永远不会有人决策），
+// 而 pi 的 worker 在 post 之后无条件等着 `permission_decision` 事件 ——
+// 长得像成功，实际永远等不到。所以「发成功了」与「什么都没发生」必须分得开。
+
+test('★ 认得出幂等命中（权限询问与代发邮件两个出口都是这个回包）', () => {
+  assert.equal(
+    isDuplicateRelay({ status: DUPLICATE_RELAY_STATUS, relay_key: 'k', detail: '该权限询问已转发过，本次调用未产生新邮件' }),
+    true
+  );
+  // 邮件出口的措辞不同，status 相同 —— 判定只看 status，不看 detail
+  assert.equal(
+    isDuplicateRelay({ status: DUPLICATE_RELAY_STATUS, relay: 'summary', detail: '该上游消息已转发过，本次调用未产生新邮件' }),
+    true
+  );
+});
+
+test('★ 反向对照：正常的 200 回包不能被当成幂等命中', () => {
+  // 误判的代价是反的：把正常请求当重复 ⇒ 明明发出去了却当场拒绝。
+  for (const res of [{}, { status: 'ok' }, { status: 'pending' }, { status: 'decided' }, { status: '' }]) {
+    assert.equal(isDuplicateRelay(res), false, JSON.stringify(res));
+  }
+});
+
+test('★ 非对象输入不炸也不误判', () => {
+  for (const v of [null, undefined, '', 'duplicate_relay', 0, false, [], ['duplicate_relay']]) {
+    assert.equal(isDuplicateRelay(v), false, JSON.stringify(v));
+  }
+  // 数组即使带 status 字段也不算（防止把响应列表当成单个响应）
+  assert.equal(isDuplicateRelay([{ status: DUPLICATE_RELAY_STATUS }]), false);
+});
+
+test('status 常量与服务端字面量一致（改一处会两边不认，这条钉住）', () => {
+  // gateway 侧：server/internal/handler/{permission,mail}.go 都写字面量 "duplicate_relay"
+  assert.equal(DUPLICATE_RELAY_STATUS, 'duplicate_relay');
+});