docs: 登记 3 条口头承诺过的未验项（此前只存在于对话里）

用户问「全部完成了是吧」时我核对了一遍，发现上一轮我**只在回复里**说过
「这项没验」，而它们**没有进任何登记文件**。

这正是本仓反复消的形状：**「说过」不等于「记着」** ——
对话一结束/一压缩，那三句就没了，而登记文件才是能活下来的地方。
（`DEBTS.json` 自己的注释就写着这条纪律：理由不能只存在于某个人当时的记忆里。）

补登记 3 条（都是 `kind: env`，即"本机能做但当前环境验不了"）：

1. `harmony-morph-unverified-middleframes`
   两处共享元素转场的**中间帧**没看到 —— `snapshot_display` 往返 1.5-3s，
   比 220ms 的动画慢一个数量级。结构/接线有判据钉着（三条变异验过会红），
   但"真的在动"只能真机看。附了本仓那条教训（探针不敏感时量的是噪声）。

2. `harmony-account-errors-banner-unverified`
   聚合失败横幅只验了「不出现」那一半。这条横幅**全部价值就在它出现的那一次**，
   所以"逻辑对齐 + 编译通过"不能算验过。

3. `harmony-permission-history-render-unverified`
   「历史 n 条」的分组是纯函数、有跨端判据，但**渲染那层**没验
   （本机 `permission_request` 0 封）。附了复现路径。

★ 顺带说明为什么这次要写进文件而不是再回一句：
  前两条我自己都**明确说过"不声称已验"**，但两次都只是消息。
  第三条更是只在 commit message 里提过。三者有一个共同点 ——
  **它们都是"我以为说过了"就够了的**，而实际不会有人回头翻聊天记录。

docs/DEBTS.json

@@ -151,6 +151,30 @@
       "where": "client/harmony/entry/src/main/ets/pages/MainPage.ets 的 PermissionTab（现在只读 /permission/pending）",
       "kind": "scope",
       "note": "**已修（2026-09-21）**。原文：鸿蒙只调 `/permission/pending`（SQL `WHERE pr.result IS NULL`）⇒ 已决策的历史完全看不到。\n\n修法与**为什么不照抄 WebUI 的 inbox 分组**：\n· WebUI 从 inbox 分组（`groupPermissions`），但它的 `PermissionRow` 只渲染\n  `subject`/`created_at`/`permission_result`/`permission_expires_at`（逐字段 grep 过）；\n· 而**待决**那一段我们要显示 `question`/`options`/`context`/`kind` —— 那四个字段在\n  `permission_requests` **表**里，inbox 回包（`models.Mail`）**没有**（模型逐条核过）。\n⇒ 待决继续走专用端点（信息更全、能直接决策），**历史**走 inbox 补上。\n  代价：每账号多一次请求。这是有意的取舍。\n\n落地：`model/MailGrouping.ts` 加 `groupPermissions` + `PermissionGroup` + `isPendingPermission`；\n`PermissionTab.load` 取 inbox 里 `mail_type=permission_request && permission_result!=空` 的，\n分组后渲染「历史 n 条」。`cross-client-logic.test.mjs` 的 `gaps` 已按提示清空。"
+    },
+    {
+      "id": "harmony-morph-unverified-middleframes",
+      "count": 1,
+      "due": "有更快的取帧手段时（snapshot_display 往返 1.5-3s ⇒ 只能验 >=3s 的动画），或用户在真机上看过并反馈",
+      "where": "client/harmony/entry/src/main/ets/common/Motion.ets 的 Motion.morph；调用点 MailDetailPage / MainPage",
+      "kind": "env",
+      "note": "2026-09-21 加了两处**共享元素转场**（geometryTransition：回复球<->回复条、写信 FAB<->写信页），结构与接线都有判据钉住（animation-audit.test.mjs 6 条，三条变异逐个验过会红），但**动画本体在设备上没能看到**。\n\n原因：snapshot_display 一次往返 1.5-3s，uitest screenCap 约 3s，而这条动画 220ms ⇒ 探针比被测对象慢一个数量级。实测连拍 4 张，y=1600 的白区跨度全是 (30,1007)（每张都已是终态）。\n\n★ 这里的教训本仓已记过一次（「探针对被测变化不敏感时，量的是噪声」——那次我连测七八轮「没有中间帧」并编出三个错误理论，最后被位移探针推翻）。这次不再重复：**如实标未验**，不声称已看到。\n\n要验它需要：能按帧取图的手段（screenrecord 在本环境不可用），或真机上手看。"
+    },
+    {
+      "id": "harmony-account-errors-banner-unverified",
+      "count": 1,
+      "due": "有一个会取失败的账号可构造时（例如故意把某账号的 server 指向不可达地址）",
+      "where": "client/harmony/entry/src/main/ets/pages/MainPage.ets 的 accountErrors 横幅",
+      "kind": "env",
+      "note": "2026-09-21 接上了聚合失败横幅（WebUI MailList.tsx:85-96 的 account-errors）。修的是一处**安全网断线**：MailStore 一直在收集 snap.accountErrors（两处 load 都写），而界面从来没读过 ⇒ 某个账号拉不到邮件时列表**静默少一整份**，界面看起来完全正常，用户会得出错误结论（「没人给我发信」）。\n\n**只验了「不出现」那一半**：本机所有账号都取得到 ⇒ 横幅正确地不显示。「真的会显示成那样」没能实测 —— 需要一个取失败的账号，本机构造不出。\n\n为什么仍值得登记：这条横幅的**全部价值就在它出现的那一次**。「逻辑对齐 + 编译通过」与「真的渲染出来」是两件事，本仓为此反复吃过亏。"
+    },
+    {
+      "id": "harmony-permission-history-render-unverified",
+      "count": 1,
+      "due": "库里存在已决策的权限请求时（UPDATE mails SET permission_result 之后即可复现）",
+      "where": "client/harmony/entry/src/main/ets/pages/MainPage.ets 的 permGroups 渲染段",
+      "kind": "env",
+      "note": "2026-09-21 闭合 harmony-permission-history 时新增的「历史 n 条」渲染。\n\n分组逻辑（groupPermissions）是纯函数、有跨端逐例判据；但**渲染那一层没验** —— 本机服务端实测 permission_request 0 封，没有已决策的权限请求可显示。\n\n复现路径：让某个 agent 发一条权限请求、人类决策一次，permission_requests.result 与 mails.permission_result 就都有值了。"
     }
   ]
 }