feat(notifications): Webhook 事件通知——给熔断/配额/健康检查装上出口

背景

系统已建成多层防护机制：熔断器、上游健康检查、密钥/上游花费配额、每日预算。但它们的状态变化目前全部是无声的——熔断打开、上游被标记 unhealthy、配额烧到上限，只有打开面板才能看到。对个人部署、无人值守的使用场景，这是系统性盲区：所有存量防护能力的产出都没有出口。

服务层现状：仅有 login-rate-limiter 等防护组件，无任何 notifier/alerting 模块。

方案：Webhook 通知通道

先做最通用的一种通道——HTTP webhook（Telegram Bot、邮件网关、Server 酱、飞书/钉钉机器人均可由用户自行转接），暂不内置具体 IM 集成。

触发事件（首批）

设计要点

• 配置为全局单例设置（可参考 traffic-recording settings 的单例模式）：webhook URL、启用的事件类型、阈值参数。
• 事件负载为结构化 JSON（事件类型、时间、主体 ID/名称、详情），供用户端模板化转发。
• 发送失败不影响主链路：异步投递、有限重试、失败仅记日志。
• 去抖/合并：同一主体同一事件在冷却窗口内不重复发（如熔断快速开合震荡时）。
• 管理 API + 设置页 UI（双语文案），含“发送测试通知”按钮。

安全注意

• webhook URL 需过 SSRF 校验（复用 upstream-ssrf-validator.ts 的口径）。
• 通知负载不携带密钥明文等敏感信息。

后续可扩展（本期不做）

• 定时日报/周报：background-sync 已有调度器，可加定时任务把 stats 聚合成摘要推送。
• 内置具体 IM 通道（Telegram/邮件 SMTP 等）。
• 用量突增异常检测告警。

Start by reading circuit-breaker.ts, health-checker.ts, api-key-quota-tracker.ts, and upstream-quota-tracker.ts to trace the listed state and threshold changes. Compare the traffic-recording settings singleton pattern and inspect upstream-ssrf-validator.ts before outlining the management API and settings UI. Done means the requested events can be configured, safely delivered as structured webhooks, tested with a test-notification action, and kept off the main request path.