dsh
974bf2a62f
fix(server): ★ relay 邮件不计入 Agent 互发上限 + 该闸放行 relay 发送 —— 修「退信把通道自己锁死」的会话死锁
症状（生产会话 0094eee5 `harmony-push-真机验证`）：
homeagent 的 3 封失败退信（relay:"summary"）被 CountTrailingAgentPingPong
计入「Agent 互发」计数，与 5 封模型主动往返合计 8 ⇒ 触发上限。之后：
· 模型每次真生成完回复再 send ⇒ 403（网关日志 09-29 22:01 ~ 09-30 10:11 共 7 笔）；
· 桥的 sendFailureReply 退信也走 /mail/send ⇒ 同样 403 ⇒ 发件人只收到
「模型未产生回复」，真因被吞；
· 被拒的尝试不产生新邮件 ⇒ 计数永不回落 ⇒ 死锁，无人能解。
发件方收到的错误与「模型没说话」在桥侧合并成同一文案（plugin.go:1022），
把内核侧限流误报成模型故障 —— 两个 Agent 各自查错了方向一整天。
根因：2026-09-26 设计第三道闸时的实测样本（pi↔dsh 175 封）里 relay=0，
于是默认这条路径上没有 relay 邮件。但插件代劳的退信同样满足
「Agent→Agent + 无人类」，被并进同一个闸。relay 本有自己的更严闸
（maxRelayHops=5），两类回路挤在同一个计数里是设计疏漏。
修法（两处，缺一不可）：
1. repo：CountTrailingAgentPingPong 跳过 relayed_mails 里登记过的邮件
（LEFT JOIN，与 CountTrailingRelayHops 同一判据源）。
2. handler：该闸加 `relay == ""` 条件 —— 即使计数已满，插件代劳的
退信/转发也必须能发出去（否则 ①② 仍在：闸拦住退信 → 真因被吞）。
红绿（生产同款数据形状）：
3 主动 + 3 relay + 2 主动 ⇒ 缺陷版数出 8（FAIL，与生产实测一字不差），
修复后 5（PASS）。人类参与打断连续性的语义不变（回归 TestAgentPingPongResetsOnHuman）。
自证边界：单测证明的是计数器与闸门的判据；「死锁会话已解锁」要在部署后
用真实会话验证（见下一笔提交）。403 文案同时删掉了「或说明为何这轮必须继续」
—— 模型的任何说明本身也要走 send，被同一道闸拦着，这条恢复路径不存在。
2026-09-30 17:08:49 +08:00
..
2026-09-25 16:29:19 +08:00
2026-09-30 17:08:49 +08:00
2026-09-19 12:30:05 +08:00
2026-09-08 19:16:35 +08:00