跨端: 闭合 harmony-permission-history —— 授权栏补上「已决策的历史」

这是 `docs/DEBTS.json` 里登记的一条，它的到期条件原文是
「做『授权栏与 WebUI 对齐』时」—— 就是现在这一轮。

## 原缺口

鸿蒙的 `PermissionTab` 只调 `GET /permission/pending`（服务端
`ListPendingPermissionsFor`，SQL 带 `WHERE pr.result IS NULL`）
⇒ **只拿得到待决的**，于是"这条会话批过哪些事"完全看不到；
而 WebUI 有（`PermissionList.tsx:182` 的「历史 {n}」）。

## 关键判断：**不照抄 WebUI 的 inbox 分组**

我先把 `PermissionTab.load` 整个改成读 inbox + `groupPermissions`，
**改到一半发现行不通**（编译报 `question`/`context`/`agent_name` 找不到）：

· WebUI 从 inbox 分组，但它的 `PermissionRow` **只渲染**
  `subject`/`created_at`/`permission_result`/`permission_expires_at`
  （逐字段 grep 过，全文件没有 `question`/`options`/`context`）；
· 而**待决**那一段我们要显示 `question`/`options`/`context`/`kind`
  —— 那四个字段在 `permission_requests` **表**里，
  inbox 回包（`models.Mail`）**没有它们**（模型逐条核过，只有 `permission_result`
  与 `permission_options`）。

⇒ 两条来源各有各的信息量，不是二选一：
  · **待决**继续走专用端点（信息更全、能直接决策）；
  · **历史**走 inbox 补上。
  代价是每账号多一次请求 —— 这是**有意的取舍**，写在代码注释里。

（半成品已 `git checkout` 撤掉，没有把它留在提交里。
 撤掉的原因如实记在注释里，免得下一个人以为"照着 WebUI 改"就行。）

## 落地

· `model/MailGrouping.ts`：加 `groupPermissions` + `PermissionGroup` +
  `isPendingPermission`，逐条对齐 WebUI 的 `groupPermissions`，
  含它那**三步排序**（有待决的先来 → 待决多的更靠前 → 最新一封倒序）。
· `PermissionTab`：从 inbox 取 `mail_type=permission_request &&
  permission_result != ''` 的，分组后渲染「历史 n 条」（只读、不可操作）。
· 空态判据从 `requests.length === 0` 改成**两者都空**才显示 ——
  否则"有待决的历史"会被误报成"没有待决策的请求"。

## 判据自己抓到了我

`cross-client-logic.test.mjs` 的「缺口只减不增」在我补上 `groupPermissions`
之后立刻变红，并给出准确指引：

    减少（harmony 补上了功能）→ 请把 gaps 里对应的名字删掉

⇒ 已清空 `gaps`。**这条判据在这轮里三次发挥作用**：
  第一次报出这个缺口（09-20），第二次在我半成品时红了，
  第三次确认闭合。`pass=7 fail=0`。

`docs/DEBTS.json` 的 `count` 已改 0、`due` 记完成、`note` 写明修法与取舍。

## 设备验证（如实）

✓ 授权页正常渲染，进程存活（23343），无新 jscrash
✓ 空态文案正确（本机确实没有权限邮件）
✗ **"历史 n 条"真的显示出来**这条路径没能实测：
  本机没有已决策的权限请求（服务端实测 `permission_request` 0 封）。
  逻辑逐条对齐 WebUI、编译通过，但我不声称已看到它渲染。

docs/DEBTS.json

@@ -146,11 +146,11 @@
     },
     {
       "id": "harmony-permission-history",
-      "count": 1,
-      "due": "做「授权栏与 WebUI 对齐」时",
+      "count": 0,
+      "due": "**已完成 2026-09-21**（本轮「授权栏与 WebUI 对齐」）",
       "where": "client/harmony/entry/src/main/ets/pages/MainPage.ets 的 PermissionTab（现在只读 /permission/pending）",
       "kind": "scope",
-      "note": "2026-09-20 由 `cross-client-logic.test.mjs` 的**缺口判据**报出来的（它要求两侧导出缺口只减不增，`groupPermissions` 是新多出来的一个）。\n\n**两端拿授权栏数据的方式根本不同：**\n· WebUI：`PermissionList.tsx:27` 拿 inbox 自己分组 —— `const groups = groupPermissions(inbox)`，每组同时渲染两段：\n    · `g.pending`（显示 `{n} 待决策`）\n    · `g.settled`（显示 `历史 {n}`，见 `:182`）\n  即**待决 + 已决策历史**都在，且按会话分组。\n· 鸿蒙：`MainPage.ets` 的 `PermissionTab` 调专用端点 `GET /permission/pending`（服务端 `ListPendingPermissionsFor`，SQL 里带 `WHERE pr.result IS NULL`）—— **只拿得到待决的**，而且是**平铺一列**，不分组。\n\n⇒ 用户可见差异：**已决策的授权记录在鸿蒙上完全看不到**（WebUI 能看到每个会话的历史条数）。\n\n★ 为什么没当场改：这不是照抄一个函数能解决的 —— 要么改成读 inbox 并实现分组渲染（结构改动），要么另调一个含已决策的端点（服务端可能没有）。两条路都要想清楚哪边是权威（本仓方向：**electron 是唯一真实源泉**⇒ 倾向于改成读 inbox + 分组）。先登记，别假装对齐了。"
+      "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` 已按提示清空。"
     }
   ]
-}
+}