fix: harden upstream and downstream receipt delivery

docs/first-version-development-requirements.md

@@ -311,6 +311,10 @@
 - 下游状态必须以客户确认作为终态：Gateway `SendPkt` 成功后只能写 `awaiting_ack`，仅收到匹配连接、`Sequence_Id`、`Msg_Id` 且 `CMPP_DELIVER_RESP.Result=0` 后才能写 `delivered`；超时、非零 Result 和历史未留存 ACK 的记录分别按未确认、拒绝或历史未确认展示，不能再把 TCP 写出冒充客户已收到。
 - 企业应用必须分别提供“回执自动重试投递”和“上行短信自动重试投递”开关，默认开启。开关按投递创建时快照保存；关闭只阻止已经写出但未获 ACK/被拒绝后的自动重发，不阻止离线队列在客户首次上线时完成首次投递。手工重投不受开关限制，但必须提示重复业务处理风险并二次确认。
 - 客户 Submit 的失败状态回执必须严格晚于对应 `CMPP_SUBMIT_RESP` 写出，且 Deliver 中的业务 `Msg_Id` 必须非 0、与该 SubmitResp 返回的 `Msg_Id` 完全一致；`Result=0` 但 `Msg_Id=0` 只能表示客户端协议栈收包，不能标记业务回执已确认。平台必须持久化原 Submit Sequence_Id，使 Gateway 重启或客户重连后的补投仍可重建相同业务 `Msg_Id`。
+- 每一次客户侧 Deliver 投递都必须单独持久化发送时间、物理连接 ID、`Sequence_Id`、业务 `Msg_Id`、ACK 截止时间和 `DELIVER_RESP` 结果；运营端详情可按尝试查看，不得只保留最后一次结果而覆盖历史。客户连接关闭时必须清理该连接的发送时序状态；无法匹配的 `DELIVER_RESP` 也必须写通讯日志。
+- 及时失败回执必须使用“当前客户物理连接上的 SubmitResp 写出屏障”：从开始处理 Submit 到该包 `CMPP_SUBMIT_RESP` 实际写出前，同一连接不得下发该 Submit 产生的失败 Deliver；长短信以最终分片 SubmitResp 写出为释放时点。屏障只控制协议写出顺序，不修改通道路由、连接配置或连接池。
+- 供应商 Deliver Receipt 必须先持久化到幂等收件箱，再返回成功 `CMPP_DELIVER_RESP`；持久化失败时不得向供应商虚假确认成功。收件箱异步匹配内部短信，支持失败退避、最大尝试/存留时间和进程异常后的 `processing` 超时恢复。
+- 上游长短信必须在每个分片收到 `SubmitResp` 后立即保存该分片的 `Sequence_Id`、供应商 `Msg_Id`、提交状态和时间，不能等待全部分片完成才批量落库；后到的提交成功聚合结果不得覆盖已经由早到失败回执形成的终态。
 - 运营端允许对 `delivered`（客户端已确认）记录再次手工重投，但单条和批量入口都必须明确提示可能造成下游重复处理；`awaiting_ack` 状态在确认窗口内不得并发重投。
 - 已实现客户侧最终 Deliver 推送的第一版能力：Gateway 在下游 Submit 被接受后记录 messageId 到客户连接的内存映射；NestJS 收到最终 receipt/uplink 并入库后调用 Gateway `/downstream/receipt`、`/downstream/uplink`，Gateway 向仍在线的客户 CMPP 连接下发 Deliver Receipt 或普通 Deliver。
 - 已实现客户侧 Deliver 持久化第一版能力：NestJS 收到最终 receipt/uplink 后写入 `CmppDownstreamDelivery` 待投递记录；在线推送成功标记 delivered，客户断线或 Gateway 不可达时保留 pending 并记录 retry 信息；客户重新 bind 后 Gateway 按账号拉取 pending 记录补发。

docs/testing-progress.md

@@ -2440,3 +2440,14 @@ git diff --check
 - 发布后Gateway、API、Nginx、PostgreSQL和MinIO均active，Redis PONG；`12026/17890/8090/3000/6379/5432/9000`均监听，API/Gateway health正常。`gateway.submit.commands`消费者1、`pending=0`、`lag=0`，3条active供应商通道均为`connected/currentConnections=1/desiredConnections=1`；API、Gateway和Nginx自发布以来关键错误匹配为0。
 - 直接调用已部署的真实`OperationsService`及PostgreSQL验证新SQL：`2026-07-24`为总量13、成功2、未知6、失败5、成功率15.4%，返回4个真实企业应用名称、4个通道和5个签名；切换`2026-07-23`为总量8、成功3、未知1、失败4、成功率37.5%，返回2个企业应用、3个通道和1个签名，证明汇总、排行、通道和签名均随所选日期切换。
 - 公网首页、运营登录页、客户端登录页和API health均HTTP 200，公网CMPP 17890 TCP连接成功。浏览器运营登录页标题正确、1280px视口无横向溢出、控制台0条error/warn；当前无已登录会话且页面存在图形验证码，未绕过验证码，因此登录后两张全宽签名表和统计图的最终视觉验收保留为人工登录复核项，不将源码/构建结果冒充登录后页面验收。
+
+## 2026-07-25 上下游回执可靠性与逐次投递审计（发布前）
+
+- 下游增加物理连接级 SubmitResp 写出屏障：从客户 Submit 开始处理到对应响应包真正写出前，同一连接产生的及时失败回执保持 pending；长短信在最终分片 SubmitResp 写出后立即补投，避免客户先收到 Deliver、后收到最后一片 SubmitResp。连接关闭会清理屏障，防止异常连接残留。
+- 每次下游 Deliver 单独写入 `CmppDownstreamDeliveryAttempt`，保存投递次数、连接 ID、`Sequence_Id`、业务 `Msg_Id`、发送/ACK 时间、ACK Result、失败类别和错误；主记录继续承载当前状态和退避调度。运营端下游投递详情新增逐次投递记录，便于区分“平台写出、客户 ACK、ACK 超时和重投”。
+- 上游长短信改为每片 `SubmitResp` 到达后立即回传 API 并写 `SmsMessageSegmentAudit`，最终聚合结果只作兜底；若早到供应商失败回执已经形成终态，后到 accepted 聚合不得把主记录倒退到 submitted，并对先扣后退场景保持幂等补偿。
+- 供应商 Deliver Receipt 改为 API `UpstreamReceiptInbox` 幂等持久化成功后才返回 `CMPP_DELIVER_RESP Result=0`。异步工作器基于保存的通道端点身份匹配短信，失败指数退避，默认最多 30 次/72 小时；API 进程在 processing 中重启时，默认 2 分钟后可重新认领，不依赖单个 Gateway 连接的内存映射。
+- 通讯日志覆盖供应商 Submit/SubmitResp、Deliver Receipt/DeliverResp、客户 Submit/SubmitResp、平台 Deliver/客户 DeliverResp；无法匹配当前 ACK tracker 的客户 `DELIVER_RESP` 也记录为失败通讯事件。内部逐分片 HTTP 回调失败另写 Gateway 结构化本地日志，不把内部回调伪装成 CMPP 报文。
+- 新增 migration `20260725160000_add_reliable_receipt_delivery_tracking`，仅新增下游逐次投递表、上游回执收件箱及索引/外键，不改写既有短信、提交、回执或投递历史。回滚必须先停止新版本 API/Gateway，再删除两张新表；回滚会丢失新版本产生的逐次投递和待匹配收件箱证据。
+- 发布前门禁通过：Prisma format/generate/validate，API 定向 3 suites / 119 tests，API 全量 26 suites / 325 tests，API TypeScript build，前端 TypeScript/Vite生产构建及 Gateway `go test ./...`。API 全量仅保留既有 Redis 不可用容错告警和 `--forceExit` 异步句柄提示；前端保留既有约 1.94 MB 单 chunk 警告。`git diff --check`通过。
+- 本节当前为发布前记录；提交、推送、数据库/源码/环境备份、migration、服务重启和预发布只读验收结果在发布完成后追加。未经额外授权不发送真实短信，不改写历史业务记录。