fix(权限): 409 的第二种含义是「本档不该问」——四桥都补上；状态写入点不再兜默认档

线上事故（jianf 经 pi 转达）：补投路径漏传 permission_mode，插件拿 undefined 兜了
workspace 档，把 full 档会话写成 workspace-write + ask —— 不是"拦一次"，是一整轮
工具能力降级，且状态留在会话里；随后该会话每次受守卫调用都撞 409。

四件事：

1. **状态写入点不接受默认值**（新增共享 `modeForStateWrite`）：缺字段/脏值 → `null`
   = 不写状态。"默认值可以出现在**决策**里，不可以出现在**状态写入**里。"
   同时保留共享契约的 fail-closed：真读到 workspace 才写 workspace。

2. **409 的两种含义分开处理**。`allowed-once` 只绕过**审批**，改不了**沙箱** ——
   所以 dsh 桥在放行前先把服务端给的权威档位**写回会话**（这也就成了自愈路径：
   已经降级的会话，下一次带档位的 409 会把它修回来）；只认服务端明说的 full，
   plan 与"链上没有人类"照旧 fail closed。

3. **同一处缺陷在 zcode / opencode 也在**（`hooks/permission.mjs` 与 `index.js`
   都把 409 当永久失败拒绝）。我先前在回信里写过"这两个桥不转发权限询问，不需要改"
   —— 那句话是错的，我当时的搜索面只有 `<plugin>/src/*.mjs`。按 pi 的要求把这条
   **否定性事实变成常驻判据**后，它第一次运行就红给我看。四桥现在都有
   「409 + full → 放行」，且**排在永久失败分支之前**（含顺序变异自检）。

4. **共用测试重新同源**：`test/catchup.test.mjs` 从 `153985e` 起就是分叉的
   （我那版把平台专属路径写进了共用文件），而 `deploy/install.sh` 第 24 行会跑
   `check-shared-libs.sh` —— 也就是说**部署一直是红的**，我没跑过那个脚本。
   共用文件只放契约（值/行为），跨平台配对judge 移到平台专属文件，四份逐字节相同。

另外把"判代码 vs 判理由"从记忆变成代码：`test/lib/read.mjs` 提供 `code()/prose()/bytes()`，
判据目录里不得再裸用 `readFileSync`（新判据 `criteria-hygiene` 管，含读取器自检）。

判据证据（每条都做过"能不能红"的变异）：
- 写回去掉 → 红；纠正块挪到普通 409 之后 → 红；状态写入点退回兜默认 → 红；
- zcode/opencode 的放行分支拿掉 → 各自红；共用测试分叉 → check-shared-libs 红。

各套件：dsh 388、pi 443、zcode 387、opencode 333（均经 npm test，含 tsc）；
electron `npm test` 15/15 判据绿 + vitest 266 + typecheck；`check-shared-libs.sh` 退出 0；
Go `go test ./...` 全 ok。

plugins/dsh-mail-bridge/src/index.ts

@@ -60,6 +60,14 @@ import {
   renderThread,
 } from '../lib/discovery.js';
 import { appendRenameProposal, renameProposalNote } from '../lib/rename-proposal.js';
+// 档位**状态写入**的共用规则（四平台逐字节同一份，见 deploy/check-shared-libs.sh）。
+//
+// ⚠️ 2026-09-14 事故记录：这两个名字是**后来补上 import 的**。当时我在 409 分支里
+// 直接用 `MODE_FULL` 却没 import，而 `npx tsc --noEmit | tail -3` 的退出码被我
+// 误当成 tsc 的（其实是 `tail` 的）—— 于是"类型检查通过"是假的，这个
+// `ReferenceError` 会在这条分支**真正被执行时**抛出：正好是它要修的那条路径。
+// 现在插件套件一律走 `npm test`（`pretest: tsc` 会先编译），不再直接 `node --test`。
+import { MODE_FULL, modeForStateWrite } from '../lib/permission-mode.js';
 import { createSSEClient } from '../lib/sse-client.js';
 import { pickMailSession } from '../lib/mail-session-id.js';
 import { normalizeAttachmentIDs } from '../lib/attachment-ids.js';
@@ -783,9 +791,23 @@ export function apply(ctx: any, config: PluginConfig): void {
   // 直接往 session 上 append 事件（与 permissionPresets.set 同一底层）。
   // 不走 permissionPresets 服务：它要求 preset 名在配置表里，
   // 而我们的三档映射需要完全自主控制。
+  // **这里是"状态写入点"，不兜默认档**（2026-09-14）：档位缺失时**跳过写入**，
+  // 保留服务端上一次给的权威值。原来写的是 `(mode || 'workspace')` —— 补投路径
+  // 漏传档位时，一条 full 档会话被**改写**成 workspace-write + ask：整轮工具能力
+  // 降级，且下一次调用照样问、照样挨 409。规则见 lib/permission-mode.js 的
+  // modeForStateWrite：默认值可以出现在**决策**里，不可以出现在**状态写入**里。
   function applyPermissionMode(session: any, mode: string): void {
     if (!session?.append) return;
-    const m = (mode || 'workspace').trim();
+    const m = modeForStateWrite(mode);
+    if (m === null) {
+      // 缺字段 = 「不知道」，不是「workspace」。日志里说清是哪条路把值弄丢了，
+      // 否则下次还是只能靠猜（这行是排查"丢字段的那只手"的第一现场）。
+      console.error(
+        '[dsh-mail-bridge] 档位缺失（事件里没有 permission_mode）：本次**不改**会话沙箱与审批策略，' +
+        '保留上一次的权威值 —— 缺字段是"不知道"，不是 workspace'
+      );
+      return;
+    }
     // sandbox mode
     const sandboxMap: Record<string, string> = {
       plan: 'read-only',
@@ -1831,12 +1853,41 @@ export function apply(ctx: any, config: PluginConfig): void {
        *
        * **只认服务端明说的 full**：plan 档（该档语义是"不动手"，拒绝是对的）
        * 与"链上没有人类"照旧拒绝 —— 猜宽了就是提权。
+       *
+       * ## 放行只修"问不问"，**修不了"能不能"**（pi 2026-09-14 指出，这条是本分支的重点）
+       *
+       * `allowed-once` 绕过的是**审批**；沙箱是另一件事，它还在 `workspace-write`。
+       * 于是"工作区外写入"这类操作会在**沙箱层**被拒 —— 功能上通了，能力上仍然窄，
+       * 而且**每次受守卫的调用都要重新走一遍 409**（放行是 per-call 的）。
+       * 更糟的是：这个状态会**留在会话里**，直到某一封恰好带档位的邮件到来。
+       *
+       * 所以这里把 409 回包当成「**服务端在纠正我的档位**」，而不是「这一次可以放行」：
+       * 回包里有权威值就**写回会话**（`applyPermissionMode`），再决定放不放行。
+       * 这顺带成了**自愈**路径 —— 连修复前就被降级的会话，也能被下一次 409 修回来。
        */
-      if (e?.status === 409 && String(e?.body?.permission_mode || '') === 'full') {
-        console.error(
-          `[dsh-mail-bridge] 服务端判定本会话为 full 档，放行本次询问（${relayKey}）：无需审批`
-        );
-        return 'allowed-once';
+      const corrected = modeForStateWrite(e?.body?.permission_mode);
+      if (e?.status === 409 && corrected) {
+        // 写回状态（权威值来自服务端，不是猜的）
+        const found = findLiveDshSession(mailSessionID);
+        if (found) {
+          applyPermissionMode(found.agent?.session, corrected);
+          console.error(
+            `[dsh-mail-bridge] 服务端纠正档位为 ${corrected}，已写回会话 ${found.id}（${relayKey}）` +
+            `—— 放行只修"这一次"，写回才修"状态"`
+          );
+        } else {
+          // 会话不在运行（插件重启后尚未收到新邮件）。
+          // 无需处理：下次投递时 deliverMail 会按邮件里带的 permission_mode 重新 apply。
+          console.error(
+            `[dsh-mail-bridge] 服务端纠正档位为 ${corrected}，但会话不在运行，写回推迟到下次投递`
+          );
+        }
+        if (corrected === MODE_FULL) {
+          console.error(
+            `[dsh-mail-bridge] 服务端判定本会话为 full 档，放行本次询问（${relayKey}）：无需审批`
+          );
+          return 'allowed-once';
+        }
       }
 
       if (e?.status === 409) {