test(channelbridge): 窗口夹具按截止时刻推钟 + 去掉无法证实的替身锁（M33 r1 复审）

P1-1（channelbridge 的 -race 门仍红，红在用例不确定性而不是竞态）：
- coalesceTimers 改成**截止时刻**语义：每次 after(d) 记 at = 注入时钟 + d，
  推钟只把时钟推进到「当前最早的截止时刻」再触发它。旧写法按 FIFO 逐个触发并
  按请求时长累加，实测 12 条消息内攒到 5 个废弃定时器把时钟推 +10s（窗口 2s、
  绝对上限 6s）⇒ 循环头走「到点直接发车、不 takeAll」的分支，队列尾部落到下一批。
- 推钟前强制「车道排空」这条不变量（pump/advanceAndFire/waitIdle）：
  时钟只表示时间过去，它一转就可能跳过 takeAll，因此先等 worker 把货收进本批。
- sendSettled：投递后按**序号**等「这次投递之后新挂的定时器」（旧的都已被 worker
  放弃、再没人监听），供「投递与推钟交替」的用例（每 500ms 一条的绝对上限用例）。
- fireLatest/advanceAndFire 带 done 谓词重试，避免「登记与触发之间续臂」导致
  推了钟却没人醒；waitIdle 一边等一边推窗口（worker 停在窗口里时永远走不到退休）。
- 用例侧只补相位与等待，不动断言：TwelveBurst 读历史前等 assistant 行落库；
  准入用例断言「最新一次续臂」（原来按下标取 d[1]，隐含臂数假设）；
  stale 用例两条都投完再推时钟（车道不会在两条之间退休）。

P2-1（替身锁无法用变异证实）选 A：删掉 stubChatter/stubSessions 的锁与访问器，
退回原字段访问，并写清理由 —— 21 个用例全走同步便捷路径
（b.process → processFrom → runBatch → Loop.Run），DEV HEAD 上 -race 数十次跑
（含把锁删掉的变异）DATA RACE 恒为 0；若将来从车道 worker 触碰这些字段必须加锁
并补 -race 用例。

证据：go test -race -count=3 ./internal/services/channelbridge/ 连跑 6 轮
18/18 全绿、DATA RACE=0；coalesce 子集 -count=80 全绿；整包 -race -count=20 全绿；
全树 go build/vet/test -count=1 全绿。

internal/services/channelbridge/coalesce_owner_test.go

@@ -123,7 +123,7 @@ func TestOwnerPrivateIgnoresEnabledConfig(t *testing.T) {
 
 	// 对照组：同一条配置对群聊**生效**（定时器被请求并按点到发车）。
 	f.send(coalesceGroupMsg("telegram", "-20", "9", "张三", "群里的消息"))
-	f.timers.advanceAndFire(t, f.clock)
+	f.advanceAndFireUntil(t)
 	close(gate)
 	chat.waitRuns(t, 2, 3*time.Second)
 	f.waitIdle(t)