feat(notify): IM 路由的主动消息也在非前台补浏览器通知（契约 v0.74）

主人裁定 C 的必然推论：她该不该提醒我，与后端走了哪条路由无关。P0 如实报回的缺口 = 通知只挂在 proactive_message 帧上，而 auto 提示在有已连接 IM 渠道时优先走 IM ⇒ 最常发生的路径恰恰不弹。

判据（先查现状、不猜）：行字段**区分不出**主动推送与普通回复（已用真库证据排除 platform/adapterId/turnId 反推）⇒ 新增**结构化的正向声明**：帧顶 data.proactive === true，只由主动推送那条通道打（gateway.BroadcastProactivePersisted）；普通路径永远传 false。
- 后端：channelbridge 抽出唯一写入口径 persistMain + 新增 proactive_notify 接缝；gateway 抽出 broadcastPersisted(msg, proactive) 两入口共用
- 前端：handlers/proactive-notice.ts 两条帧路共用同一套提醒运行时（有界去重 + 降级说明 + DOM/Notification 取值）；message.ts 读到判据才走提醒
- 对照断言（必须有）：普通 IM 回复/主人提问/显式 proactive:false ⇒ **0 通知、3 气泡**（不误伤）
- 变异实测：去掉非主动保护 / 跨两路去重失效 / 前台也弹 / IM 不发判据帧 / 普通广播带判据 ⇒ 5 条全部打红
- 契约 v0.74（纯增量：message_persisted 新增可选 proactive:true）
- 边界（如实）：判据**不落库**（翻历史不弹提醒，也不得从行字段反推）；落库失败时不发判据帧（无权威 id 的帧前端整帧丢弃）

internal/services/channelbridge/proactive.go

@@ -40,6 +40,12 @@ const proactiveRecentCount = 20
 // 当主人档案没有白名单账号、或该账号没有已连接的
 // 适配器支撑时，它返回明确错误，便于调用方记录原因，
 // 而不是静默丢弃推送。
+//
+// 成功投递之后它**同时**做两件事：把这条主动消息镜像回主会话（恰好一次；气泡恒落的
+// 根），并让实时通道能凭**结构化判据**认出「这条是她主动说的话」—— 后者是切片 P0b：
+// `auto` 提示在主人有已连接 IM 渠道时优先走 IM，因此**实际最可能发生的路径**恰恰是这
+// 一条；它过去只发普通 `message_persisted`，于是挂在 `proactive_message` 上的浏览器
+// 通知永不触发（主人裁定：该不该提醒与走哪条路由无关）。
 func (b *Bridge) SendProactive(ctx context.Context, msg adapter.UnifiedMessage) error {
 	if err := ctx.Err(); err != nil {
 		return err
@@ -77,16 +83,39 @@ func (b *Bridge) SendProactive(ctx context.Context, msg adapter.UnifiedMessage)
 	// 把主动消息镜像进主对话上下文（design/16
 	// §4.4 + §4.6.1）。否则模型看不到自己主动说了什么，
 	// 主人后续回复就会显得不连贯（该消息「丢失」了历史）。
-	// 它与主人私聊 IM 回复走同一条镜像路径，作用域为 MainSessionID，
-	// 落库的同样是规整后的那一份（Web 与 IM 看到的必须是同一份）。
-	// turn_id 传 ""：主动推送是**她单方面开口**，没有对应的入站回合，也就没有
+	// 它用的是普通回复那条写入口径（persistMain，相同的列、相同的时间戳语义），
+	// 作用域恒为 MainSessionID，落库的同样是**规整后**的那一份（Web 与 IM 看到的必须是
+	// 同一份），因此落库行为与本切片之前逐字相同；变的只有通知的第二步（见下）。
+	// turn_id 传 ""（零值）：主动推送是**她单方面开口**，没有对应的入站回合，也就没有
 	// 「它属于哪一路回合」可归属 —— 空值诚实地表示这一点（见 turnid.go 的口径）。
-	b.persistToMain(ctx, history.RoleAssistant, out.Content, "", "", "", target.platform,
-		fmt.Sprintf("%s:%s:%s", target.platform, target.accountID, target.accountID),
-		target.platform, "")
+	//
+	// 通知分两步，两条都是**结构化**的通道（绝不是「像不像主动消息」的猜测）：
+	//   ① notifyPersisted 照旧 —— 这就是 P0 起的行为，任何客户端都能渲染这条镜像消息，
+	//      逐字不变（`message_persisted`）；
+	//   ② 再走 notifyProactive —— 追加一条帧顶带 `proactive:true` 的同类帧，客户端据此在
+	//      **非前台**补一发浏览器通知（切片 P0b）。两帧说的是同一条消息（同一个落库行
+	//      id），前端按 id 去重 ⇒ 仍是一个气泡、仍只提醒一次。
+	//
+	// ② 只在**确实落了库**时发：`message_persisted` 的载荷要求权威 id，客户端拿不到 id
+	// 会整帧丢弃 —— 发一条没有 id 的帧等于假装提醒过。落库失败本身已由 persistMain
+	// 记 WARN（可见，不静默）。
+	row := history.Message{
+		SessionID: history.MainSessionID, Role: history.RoleAssistant, Content: out.Content,
+		Platform: target.platform, DeviceID: proactiveDeviceID(target), AdapterID: target.platform, Mode: modeChat,
+	}
+	if full := b.persistMain(ctx, row, b.notifyPersisted); full.ID != "" {
+		b.notifyProactive(full)
+	}
 	return nil
 }
 
+// proactiveDeviceID 是主动推送落进主会话时写入 device_id 的标签：`<平台>:<账号>:<账号>`。
+// 它不是某台设备，而是「这条推送走的是哪个主人渠道账号」——与 sendIMBubbles 出口选中的
+// 那个账号逐字对应，因此在管理日志里能一眼看出这条主动消息投到了哪里。
+func proactiveDeviceID(target proactiveTarget) string {
+	return fmt.Sprintf("%s:%s:%s", target.platform, target.accountID, target.accountID)
+}
+
 // proactiveTarget 解析主动推送应当到达的唯一主人账号。
 // 候选范围是每个有已连接适配器支撑的白名单主人渠道
 // （含 WeChat），选择遵循 backthink 的优先级：