docs: B-8 在 HomeAgent 上是 N/A（平台无审批环节），补齐平台矩阵第四列

B-8 的 homeagent 那格一直标着「❌ 要先摸清 homed approval API」。
查清了：**那个 API 不存在，而且不该存在。**

判据：SDK 与核心两处 grep `approval|consent|permission|confirm`，
命中数均为 0。

前置条件是「平台本来就要问人」。另三个平台各有一个现成的审批环节
（opencode `permission.ask` / DSH `approval/request` / pi `tool_call`），
桥做的只是把它从本地 TUI 改道到邮件通道 —— 没有发明审批协议。

HomeAgent 的核心是纯思维核：本身无对外交互能力（全部能力来自插件），
也没有会话这一层（单事件循环）。它不问人，工具调用直接执行。

它确实有 `StageBeforeToolcall` 可以拦下调用（`process.go:273`，插件给
`ctx.Response` 赋值即拒绝，核心把「工具 X 已被插件拒绝」喂回模型）。
但那是「插件可以否决」而非「平台在征求同意」：没有待批准的请求、
没有选项、也没有等人的语义。

所以 B-8 是 N/A 而不是待办。硬补等于给平台加它本来没有的能力 ——
要自己划高风险工具白名单、自己定义超时与 fail closed、自己决定人不在时
怎么办，那些是产品决策不是契约合规。

顺带记下一个需要知道的事实：homeagent 的工具全部无条件执行（含 cmd_run），
接入邮件之后任何能给它发信的人或 Agent 都能间接触发，中间没有人类确认。
另三条链至少有 409 兜底，这条没有 —— 因为它根本不发起询问。
这不是缺陷而是那个平台的信任模型（homed 跑在用户自己机器上，默认完整权限），
记下来是为了让「谁能给 homeagent 发信」被当作访问控制来对待。

平台差异对照表补齐 HomeAgent 一列（14 行）。它是四平台里唯一**不需要**
为每封邮件开平台侧会话的：没有会话概念，所有邮件注入同一事件循环，
靠 output_send__agentmail 输出通道送回复。

docs/PHASE7-REMAINING.md

@@ -355,3 +355,63 @@ T 前的 `M`（月）与正号 trigger 一律忽略而不是乱换算）。
   会被截断。常见客户端导出的短字段不受影响
 - `RRULE` 只认 `FREQ=`，忽略 `INTERVAL`/`BYDAY`/`COUNT`/`UNTIL`
 - 周/日视图不按小时定位色块高度（事件都是等高行，不体现时长）
+
+
+---
+
+## B-8（权限询问转邮件）在 HomeAgent 上不适用
+
+四平台能力矩阵里 homeagent 的 B-8 一直标着「❌ 要先摸清 homed approval API」。
+本轮查清了：**那个 API 不存在，而且不该存在。**
+
+判据：在 SDK（`third_party/homeagent-sdk/sdk/*.go`）与核心
+（`internal/**/*.go`）两处 grep `approval|consent|permission|confirm`，
+命中数均为 **0**。
+
+原因是设计取向不同。另三个平台各有一个现成的审批环节，桥做的只是把它从
+本地 TUI **改道**到邮件通道：
+
+| 平台 | 审批钩子 |
+|---|---|
+| opencode | `permission.ask` |
+| DSH | `approval/request` |
+| pi | `tool_call` |
+
+HomeAgent 的核心是一个**纯思维核** —— 本身没有任何对外交互能力，
+全部能力来自插件，也没有会话这一层（单事件循环）。它不问人：
+工具调用直接执行。
+
+它确实有一个可以拦下调用的位置：`StageBeforeToolcall`
+（`internal/agent/core/process.go:273`，插件给 `ctx.Response` 赋值即视为拒绝，
+核心会把「工具 X 已被插件拒绝」当作 tool 结果喂回模型并发 `status: "denied"`
+事件）。但那是「插件可以否决」而不是「平台在征求同意」：没有待批准的请求、
+没有选项、也没有等人的语义。
+
+**因此 B-8 在这个平台上是 N/A，不是待实现项。** 硬要补等于给平台加一层
+它本来没有的能力：要自己划高风险工具白名单、自己定义超时与 fail closed
+语义、自己决定人不在时怎么办 —— 那些都是产品决策而不是契约合规。
+（技术上可行：`RegisterTool` 的 handler 是我们的代码，能在执行前发权限邮件
+并阻塞等待；`InjectInputSync` 证明这套 SDK 里「同步等外部答复」是既有形态。
+但没有需求驱动就不做。）
+
+### 随之而来的一个事实，需要知道
+
+homeagent 的工具**全部无条件执行**，其中包括 `cmd_run` 这类能力。
+它接入 AgentMail 之后，任何能给 `homeagent@…` 发信的人或 Agent 都能间接
+触发这些工具，中间没有人类确认环节。
+
+另三条链上至少有一道兜底：桥收到 409（Gateway 判定整条会话树上没有人类
+可路由）时当场表态拒绝。homeagent 这条链没有这一环 —— 因为它根本不发起询问。
+
+这不是缺陷，是那个平台的信任模型：homed 及其插件都跑在用户自己的机器上，
+默认完整权限。记在这里是为了让「谁能给 homeagent 发信」这个问题被当作
+访问控制来对待，而不是当作邮件权限。
+
+### 契约文档的改动
+
+- `B-8` 标题从「若平台支持，MUST」改为「若平台有**审批环节**，MUST；没有则 N/A」，
+  并补一段说明前置条件与 `StageBeforeToolcall` 的语义差异
+- 平台差异对照表补齐 **HomeAgent 一列**（14 行）。它是四个平台里
+  唯一不需要为每封邮件开平台侧会话的 —— 没有会话概念，所有邮件注入同一个
+  事件循环，靠 `output_send__agentmail` 输出通道送回复
+- 检查清单里「未决权限询问 fail closed」标注适用条件