fix(channelbridge): M44 入站语音先写 voice 列再广播 ⇒ 首帧就带 voice

安卓 2026-10-26 回执关心的场景：新来一条语音消息时，**第一条**帧里有没有
`voice`。此前没有 —— `persistBatchUsers` 先 `persistToMain`/`persistIsolated`
（内部同步 notify 把帧发出去），之后才 `persistMessageVoice` 写列，帧发出那
一刻列还是空串。网关侧的帧投影（上一 commit）读的就是这一列，因此首帧必然
缺 voice，客户端要等重连或下一次 REST 拉取。

修法（A 路的唯一可行形态，理由见下）：
- `persistBatchUsers` 的通知改成 `persistVoiceFirstNotify(ref)`：
  **INSERT → 写 voice 列 → notify**。语句数不变，只把 notify 从 INSERT 内部
  挪到最后；非语音消息（ref 零值）时该包装与 `notifyPersisted` 逐字等价。
- `persist.go` 抽出 `mainRow` / `isolatedRow`（字段清单只写一次）与
  `persistIsolatedWith`（可注入通知的变体），`persistToMain`/
  `persistIsolated` 的对外行为逐字不变。

为什么不走 B（给 `history.Message` 加 voice 随 INSERT 写）：`persistMessageVoice`
是按 id 的 UPDATE，行还不存在时必然 `ErrMessageNotFound` ⇒ 写列**不可能**真正
挪到 INSERT 之前；可行的最小形态就是上面那次换序，无需动 domain 类型、列清单
与 7 条读语句。B 若要做，属于 design/24 §10.5 的独立切片（那时还应删掉这里的
两段式，避免同一事实两处写）。

整链验收（`inbound_voice_gateway_e2e_test.go`，真桥接器 + 真存储 + 真网关 WS）：
- 主人私聊语音：第一帧就是 `message_persisted`，带 `voice`，且与
  `GET /sessions/{id}/messages` 同一行**逐字相等**；随后的非语音消息帧整键缺席。
- 群聊语音（被点名 ⇒ 走完整回合）：第一帧 `channel_persisted` 带 `voice`，
  且与渠道日志读面同一行逐字相等。
- 变异实测（把顺序还原成「先广播、后写列」）：两条用例都 FAIL，输出即报障症状
  （帧里 content 是转写文本，却没有 voice 键）。

顺带把网关侧两处描述旧时序的注释改成新事实。

internal/services/gateway/broadcast.go

@@ -66,6 +66,10 @@ func (s *Server) broadcastPersisted(msg history.Message, proactive bool) {
 // 「同一行消息在帧里与 GET /sessions/{id}/messages 里」是逐字相同的对象，客户端不必
 // 再拉一次 REST 才认出语音气泡。
 //
+// 帧上的 `voice` 反映的是**本帧发出那一刻**的列值 ⇒ `voice` 列的写入必须先于 notify。
+// 入站语音那条路已由 M44 倒好顺序（channelbridge 的 persistVoiceFirstNotify），
+// 否则这条语音消息的第一帧会读不到 voice。
+//
 // 代价（实测，见交付报告）：每帧**一次**批量读列（`IN (?)` 一条 SQL，页内 id 去重），
 // 与本路径既有的 unreadCountOf 查询同量级；存储未提供该视图时**零**查询、字段缺席。
 // 之所以要查库而不是「从 history.Message 直接填」：那个结构体没有 voice 列字段

internal/services/gateway/history_voice.go

@@ -26,11 +26,10 @@ package gateway
 // （`ws_history.go`）。三条收口点共用本文件这一份投影，因此「同一条消息在 REST 读面与
 // 实时帧 / 回放里的 `voice` 对象」逐字相同，不会两处各算一份。
 //
-// ⚠️ 实时帧那条路的**已知边界**（不在本文件能修的范围内）：入站语音的 `voice` 列由
-// 渠道桥在**消息落库之后**回填（channelbridge 的两段式），而 `message_persisted` 那一帧
-// 在**落库那一刻**就发出去了 ⇒ 这一帧读到的列仍是空串、`voice` 依旧缺席；紧随其后的
-// 握手回放 / REST 拉取才带上它。要让「刚落库的那一帧」也带上，须把渠道桥的两段式顺序
-// 倒过来（先写列、再 notify），见交付报告与 Docs §4.4 的同一处如实登记。
+// ⚠️ 实时帧那条路对**时序**有依赖（已由 M44 的跨层修复保证）：`voice` 是**读列**得来的，
+// 所以帧必须在 `voice` 列写好之后才发出。渠道桥原来「先 notify、后写列」，导致入站语音的
+// **第一帧**读不到 voice；M44 把它改成「INSERT → 写 voice 列 → notify」（见 channelbridge
+// 的 persistBatchUsers / persistVoiceFirstNotify），本文件因此无需再区别对待实时帧与读面。
 
 import (
 	"context"