docs: PLUGIN-GUIDE 重写为 PLUGIN-CONTRACT（可核对的插件规格）

原 PLUGIN-GUIDE 是叙事式的「怎么做 + 踩过的坑」，读者要自己从散文里推断
「我到底必须做什么」。接第三个平台时这不够用 —— 尤其当照着实现的是一个代理。

改为规格式，编号可引用、强度明确标注、每条尽量给出可机械核对的判据。
旧文档的内容全部保留（迁进第八、九节），另补上原先没有的四类：

## 一、能力矩阵（新增）

回答「这个平台能不能接」。七项必需能力（C-1..C-7）加七项可选（C-8..C-14），
每项给出判据。附一个七问自检 —— 任何一问答不出来就先别写代码。

其中 C-4「轮次结束信号必须能区分成功与出错」在两次适配里都被漏掉过，
两次都造成「无效模型被判成成功」，所以单独标了出来。

## 二、行为约定（重写）

原先散在各节的要求收拢成一个状态机，按事件逐条规定：B-1 启动 / B-2 心跳 /
B-3 new_mail / B-4 permission_decision / B-5 轮次结束 / B-6 无法处理时回信 /
B-7 启动补拉 / B-8 权限询问 / B-9 关停。

## 四、降级语义（新增）

平台缺某项能力时的确切退化路径（D-1..D-7）。原文档只说了「可选」，
没说缺了之后该怎么办 —— 于是「不支持权限钩子」很容易被实现成
「提供 request_permission 工具补偿」，而那正是 I-1 反对的模式。

## 六、不变量与禁止事项（新增）

12 条 MUST NOT，每条附「违反会怎样」。这些是测试全绿、跑起来也不报错，
但行为就是错的那类问题 —— 例如拉取失败时传 [] 而非省略字段会清空服务端目录。

## 七、验收清单（新增）

八组可勾选项，每条给出具体命令：grep 自查禁止事项、sqlite3 查在线状态与
配额未被消耗、停插件发信再启动看补投日志。

## 核对过的事实

写完逐项核对了代码，不是凭记忆：
- 12 个端点全部在 main.go 里存在且方法一致
- 发信 9 个字段名与 sendMailRequest 的 json tag 一致
- 心跳响应 12 个字段名与 handler 一致
- 九个数字（30s 心跳 / 25MB 附件 / 20 次每小时 / 补投 5 封 / 快照 200 条 /
  模型上限 10 / 目录上限 300 / 降级超时 60s / inbox 默认 5）都能在代码里找到出处
- 验收清单里的六条 sqlite 查询都在生产库上跑通
- 38 个编号无重复，18 处交叉引用全部有定义

引用同步：PLAN.md、PHASE7-REMAINING.md、API.md、README.md、
install.sh、check-shared-libs.sh。

README.md

@@ -129,7 +129,7 @@ agentmail/
 ├── docs/
 │   ├── PLAN.md              # 分阶段实施计划
 │   ├── MVP-SPEC.md          # MVP 技术规格书
-│   └── PLUGIN-GUIDE.md      # Agent 平台插件适配指南
+│   └── PLUGIN-CONTRACT.md   # Agent 平台插件契约（规格 + 验收清单）
 ├── gateway/                 # 后端（Go，单二进制）
 │   ├── cmd/server/          # 入口与路由表
 │   └── internal/
@@ -254,6 +254,7 @@ Agent 干完活可以在正文里**提议**改成更贴切的名字，但改不
 ## 文档
 
 - [WebAPI](docs/API.md) — 接口清单、认证方式、错误约定
-- [插件适配指南](docs/PLUGIN-GUIDE.md) — 接一个新 Agent 平台要实现什么，以及踩过的坑
+- [插件契约](docs/PLUGIN-CONTRACT.md) — 接一个新 Agent 平台的规格：能力矩阵、行为约定、
+  降级语义、线协议、不变量、验收清单，以及两次适配踩过的坑
 - [实施计划](docs/PLAN.md) — 分阶段任务与验收标准
 - [MVP 技术规格书](docs/MVP-SPEC.md) — 数据模型与接口细节