test(channelbridge): 准入三条用例改按「这条消息续出的臂」断言（M33 r2 复审 p2）

TestCoalesceSystemNoticeDoesNotJoinBatch 仍在用位置索引 d[1]：waitTimerCalls 只保证
「至少 2 次请求」，不保证顺序 —— 加压下会拿到 m1/m2 那次 2s 的续臂（实测 -race
-count=200 有 2/200 假红，空载测不出来）。

改成与兄弟用例同一口径，但把相位做成确定的：新增 sendSettledAndDuration ——
投递后等 worker 把这条收进本批、**为它**续好臂（按请求序号认领），再返回那次续臂的
时长。仅用 latestDuration 仍有缝：worker 可能在帧/通知之后才补上一条消息的续臂，
最新那次就成了 2s。三条准入用例（action 帧 / 系统通知 / 聊天消息对照组）统一改用它。

断言口径未变：仍然断言「系统通知/action 帧不重置静默窗口（剩余 500ms）」、
「聊天消息重置成完整 2s」；waitTimerCalls 语义、请求次数均未改。

证据：-race -count=400 连跑 3 次（1200 次）全绿、DATA RACE=0；
兄弟两条 -count=200 全绿；整包 -race -count=3 全绿。

internal/services/channelbridge/coalesce_fixture_test.go

@@ -499,3 +499,14 @@ func (h *laneHistory) waitRows(tb *testing.T, sessionID, role string, want int,
 	}
 	tb.Fatalf("等了 %s 仍只有 %d 行 %s（want %d）", timeout, len(h.snapshot(sessionID)), role, want)
 }
+
+// sendSettledAndDuration 投递一条并返回**这条消息之后 worker 续出的那次窗口时长**。
+//
+// 它把「投递 → worker 收进本批 → 为它续臂」做成一个确定的相位：续臂用请求序号认领
+// （`seq > 投递前`），因此不会把此前那条消息的续臂误当成这一次的 —— 只按「至少 N 次
+// 请求 + 取最新」在负载下仍会拿到上一条的时长（实测 -race -count=200 有 2/200 假红）。
+func (f *coalesceBridge) sendSettledAndDuration(t *testing.T, msg adapter.UnifiedMessage) time.Duration {
+	t.Helper()
+	f.sendSettled(t, msg)
+	return latestDuration(f.timers.durations())
+}