fix: reconcile shared-channel receipts and protocol logs

docs/testing-progress.md

@@ -2341,3 +2341,23 @@ git diff --check
 - Gateway重启后5条启用上游通道中3条立即连接，“富泷物业-联通/电信”共享账号`C59748`首次被供应商返回`auth failed`；自动重连按`nextReconnectAt=11:00:58`执行后两条均恢复。最终5/5通道全部`connected/currentConnections=1/desiredConnections=1`，最近心跳持续刷新，`lastError`和`nextReconnectAt`清空。
 - 公网首页、运营登录、客户端登录和API health均HTTP 200，公网CMPP 17890 TCP连接成功。真实运营账号通过算术验证码登录，在“系统日志→通讯交互日志”看到预发布CMPP连接的`received/success`事件、耗时和固定详情列；浏览器控制台0条error/warn。
 - 发布后API/Gateway日志未出现panic、fatal、unhandled、exception、通讯日志批量写入失败、回执解包失败或API转发失败；Nginx无error/crit/emerg。未发送真实短信、未充值、未审核、未删除或修改业务对象。
+
+## 2026-07-24 通讯日志方向与重复记录修正（本地未提交、未部署）
+
+- 复核预发布号码`18821203795`对应消息`MSG-TEST-1784863949078-b28e828d`确认：原页面四条记录全部显示“通道→平台”，不是四个完整协议报文，而是仅采集了Gateway转入NestJS的`CMPP_SUBMIT_RESP`和`CMPP_DELIVER`，并把每个报文各拆成`received/success`两行；真实下行`CMPP_SUBMIT`与`CMPP_DELIVER_RESP`此前未采集，因此箭头虽符合现有事件入口方向，但不足以表达完整交互并造成重复观感。
+- 改为“一条数据库记录对应一个真实业务报文”：NestJS不再为同一入站报文分别写`received`和`success`，只落最终成功或失败结果；Go Gateway在真实`SendReqPkt(CMPP_SUBMIT)`及`SendRspPkt(CMPP_DELIVER_RESP)`写包完成后异步上报平台→通道事件。正常短短信完整成功闭环将显示`CMPP_SUBMIT → CMPP_SUBMIT_RESP → CMPP_DELIVER → CMPP_DELIVER_RESP`四条真实报文及实际传输方向；历史`received`行保留并标记为历史，不修改既有预发布数据。
+- Gateway遥测使用独立goroutine和既有HTTP超时，不阻塞发送/回执读循环；API仅接受`cmpp + platform_to_channel + submit/deliver_resp + success/failed`白名单事件，不接收正文、密码或密钥。
+- 本地使用真实NestJS API、真实算术验证码管理员会话和真实PostgreSQL写入两条安全的合成出站协议事件（未发送短信），再从运营端查询`MSG-DIRECTION-SMOKE`，页面正确显示“平台→通道 / CMPP_SUBMIT / 已发送”和“平台→通道 / CMPP_DELIVER_RESP / 已发送”；浏览器控制台0条error/warn。
+- 自动化验证：新增Controller单元测试覆盖入站单报文单记录和Gateway白名单，新增Go测试覆盖出站遥测payload；API全量、API/前端构建、Prisma validate、Gateway全量测试及`git diff --check`结果见本次会话最终记录。
+- 当前修改保持未提交、未推送、未部署；预发布仍运行`0bfeb0839ee6b67611e13796f46c19fc05b88de9`，发布前不得把本地验证结果误认为预发布已生效。
+
+## 2026-07-24 跨连接回执、长短信聚合与通讯日志闭环修复（发布前）
+
+- 对号码`13127620092`的预发布只读证据确认：两分片均已由供应商受理，第二片回执从同账号复制通道连接返回。Gateway内存映射按物理连接隔离，未找到原提交后上报了`receipt-736070230367350788`和当前连接通道；NestJS又要求`channelId + gatewayMessageId`严格一致，最终通讯日志显示`SMS message record not found`。首片`DELIVRD`同时提前把主记录改成`delivered`，没有等待第二片，是独立的长短信聚合缺陷。
+- 回执匹配增加分片审计路径，并把“同供应商”固定为账号、Gateway主机、端口、协议和CMPP版本全部一致。只有`gatewayMessageId + DestTerminalId`在该供应商范围内唯一时才允许跨物理连接认领；回执、幂等键和主记录仍归属原提交逻辑通道。不同供应商或候选不唯一继续拒绝，避免串单。
+- 长短信每片回执先写`SmsMessageSegmentAudit`。部分成功时主记录保持`submitted`且不向企业应用投递最终回执；全部分片成功后才聚合为`delivered`并投递一次。任一明确失败进入既有最终失败/补发路径，重复回执继续由逻辑通道回执键幂等。
+- 通讯日志改为一条真实业务报文一条记录：供应商长短信每片真实`SUBMIT/SUBMIT_RESP`分别采集，内部`submit-result`聚合回调不重复落协议日志；Gateway补充供应商`SUBMIT`、`SUBMIT_RESP`、`DELIVER_RESP`和企业应用`SUBMIT_RESP`出入方向。运营端方向名称统一为“企业应用→平台、平台→供应商通道、供应商通道→平台、平台→企业应用”，回执成功处理后用真实主消息ID替换临时`receipt-*`标识。
+- 新增回归覆盖：同供应商副连接唯一匹配、不同供应商拒绝、两分片未齐不提前送达、全部到齐一次聚合、内部回调不重复记录、入站服务真实SubmitResp遥测及安全白名单。API定向2 suites/90项、API全量26 suites/313项、Gateway全量`go test ./...`和`go vet ./...`、API/前端build、Prisma generate/validate/status（本地67条migration最新）、`git diff --check`均通过。
+- 使用当前构建启动独立本地NestJS API，连接真实PostgreSQL和Redis执行`tools/smoke/receipt-cross-connection-smoke.mjs`：第二片从副连接进入后回执行的逻辑通道为原通道、主记录保持`submitted`；第一片补齐后主记录为`delivered`，恰好2条回执和2个已送达分片，脚本最终清理全部合成业务数据。
+- `verify:phase8`首次使用共享Redis且本机已有API争用时为373.05 TPS，低于500阈值，明确记为失败；改用独立临时Redis完整重跑为764.69 TPS并通过，临时Redis随后停止。前端仅保留既有约1.93MB单chunk警告。
+- 本次不新增Prisma模型或migration。发布后仍需只读确认服务、67条migration、Redis Stream、5条供应商通道重连、通讯日志新方向和近期错误；未经单独授权不发送真实短信，也不改写`13127620092`历史业务记录。