fix(history,loop,gateway): 上下文续接的最新性/一致性三条（裁决 13.4.5 的面内部分）

本组只落地「在允许文件面内、且能用 design/15 既有规格推出」的部分；13.4.5 的「真并行 + 动态旧上下文」
与 design/15 §2.1/§2.2 的既有串行续接规格存在读法冲突，按规程**停下上报**（未自创语义）。

- history.Recent（续接窗口）并列打破：created_at DESC, rowid DESC —— Windows time.Now() 步长 ~0.44ms，
  用户连发必然同毫秒并列；修复前并列时取**更早**的 ⇒ 丢掉刚发出的最新 n 条且同毫秒内反插入序
- 上行 chat 不再经**可丢弃**的 bus：直达会话编排器的非阻塞 Submit（design/15 §2.1「会话消息不能被 drop」
  + §4「不阻塞是硬约束」）；orchestrator 为 nil 时回退 bus，旧断言仍绿
- 被**取消**（中断）的回合把该会话 checkpoint 落定为不可恢复（用 context.WithoutCancel 写，快照保留可查询，
  仅在回合未落定时触发）⇒ 不再顶掉下一条消息的上下文
- 复核：build/vet 绿 + loop/gateway/history 三包测试与 -race 全绿；新增 5 条用例（含一条真 WS+真编排器+
  真 loop+真 persist 的集成用例）；**3 条变异反证**精确复现「新消息被丢弃只见旧窗口」「窗口取早不取新」
  「bus 饱和时会话消息静默消失」，均已还原
- 待裁决（已上报主人）：① 「同一会话多回合真并行」需改 checkpoint 键（sessionID:step 并发互相覆盖）、
  flow 图按轮键控、前端单槽 busy —— 均在本组文件面外；② 「动态吸收新到消息」在 design/15 **无规格**，
  属新语义，须先写设计；③ 非取消的错误退出同样留可恢复快照（同机制，未扩范围，因 resume_test 正钉住旧行为）

internal/runtime/history/store.go

@@ -444,12 +444,19 @@ func (s *Store) ListAllLog(ctx context.Context, before int64, limit int) ([]Mess
 
 // Recent 按最旧优先返回 sessionID 最近的 n 条消息（最靠尾部的那段窗口），供
 // WS 回放 / 上下文尾部使用。返回切片非 nil。
+//
+// 并列打破（裁决 13.4.5 的上下文「最新性/一致性」）：同一毫秒写入的多条消息
+// 在 created_at 上并列，而 Windows 上 time.Now() 的步长本就约 0.44ms —— 用户
+// 连发多条（design/15 §2.1 的忙碌续接场景）时并列是常态。`rowid DESC` 让 LIMIT
+// 取到的是**最后插入**的那几条（否则窗口会留下更旧的、丢掉刚发出的），而反转后
+// 同毫秒内即回到插入顺序，使续接窗口的时序与真实对话一致。该口径与 ListAfter
+// 的「rowid 打破 created_at 的并列」相同。
 func (s *Store) Recent(ctx context.Context, sessionID string, n int) ([]Message, error) {
 	if n < 1 {
 		n = defaultPageLimit
 	}
 	rows, err := s.db.QueryContext(ctx, `SELECT id, session_id, role, content, mode, mood, image, thinking, platform, device_id, sender_name, adapter_id, persona_id, created_at
-		FROM chat_messages WHERE session_id = ? ORDER BY created_at DESC LIMIT ?`, sessionID, n)
+		FROM chat_messages WHERE session_id = ? ORDER BY created_at DESC, rowid DESC LIMIT ?`, sessionID, n)
 	if err != nil {
 		return nil, fmt.Errorf("history: recent %s: %w", sessionID, err)
 	}