feat(通知): 加钉钉 / 飞书两种格式（含各自的加签算法）

## 两家签名算法不一样，照抄必错
| | 钉钉 | 飞书 |
|---|---|---|
| HMAC key | `secret` | `"{timestamp}\n{secret}"` |
| 被签内容 | `"{timestamp}\n{secret}"` | 空 |
| timestamp | 毫秒 | 秒 |
| 拼在哪 | URL query | JSON body |
| 结果 | Base64 再 urlencode | Base64 |
| 出错码 | `errcode 310000` | `code 19021` |

实现为 `BaseAdapter.sign_request()` 钩子（默认不动），两家各写各的；
`core/notifier.py` 的 `_post_once` 在发请求前调用它。

## 另外
- 钉钉：markdown 消息（title+text）；成功码 0；默认限流 15/分（官方 20/分，**超限会被限 10 分钟**，留余量）
- 飞书：交互式卡片（header 颜色按事件级别 + markdown 元素）；成功码 0；默认 60/分
- `PLANNED_FORMATS` 清空（下拉里不再有置灰项）
- **修一个泄漏**：`mask_url` 原来只打码 query 参数——**飞书的 token 在 URL 路径里**（`/hook/<token>`）
  → 接口回显会漏出去。现在同时处理路径 token（≥20 位随机串）与 Slack 的 `/services/T…/B…/X…` 三段。

## 验证（都跑过）
- **签名对拍官方示例**：钉钉逐字节一致（含 urlencode，`%2B` 级别）、飞书的 key/message 口径一致；
  时间戳钉住后比对，不靠"自己跟自己一致"
- 成功码按格式：wecom/dingtalk/feishu 的 0 与 bark 的 200 分别判成功，各自的错误码判失败
- 端到端 15 项：钉钉/飞书在假接收端上真发（URL 带签名、body 带 timestamp/sign、卡片是 markdown 元素、
  毫秒 vs 秒的时间戳），签名错时正确判失败（310000 / 19021），token 在回显里被打码

README.md

@@ -53,7 +53,7 @@
 | **AI 控制台** | 用自然语言驱动 AI 操作指定设备（MCP 工具 + 截图），流式输出、Markdown 渲染、推理链折叠、token 统计；成功操作自动沉淀「经验库 / 动作库」并在相似任务中召回 |
 | **MCP 接入** | 20 个 `de_*` 工具，把手机控制开放给外部 AI；写操作有开关、设备忙时拒绝、全量审计 |
 | **备份导出/导入** | 一键导出 zip（库快照 + manifest + 可选 APK），导入前校验预览、自动预备份、重启生效 |
-| **通知 / Webhook** | 任务成功失败、设备上下线、安装完成、备份恢复等事件推送到企业微信 / Bark / 自建服务；多条 webhook 各自订阅；聚合+限流防刷屏（见 [doc/NOTIFY.md](doc/NOTIFY.md)） |
+| **通知 / Webhook** | 任务成功失败、设备上下线、安装完成、备份恢复等事件推送到企业微信 / 钉钉 / 飞书 / Bark / 自建服务（Slack 用通用 JSON）；多条 webhook 各自订阅；聚合+限流防刷屏（见 [doc/NOTIFY.md](doc/NOTIFY.md)） |
 
 ---