fix: reassemble inbound CMPP long messages

docs/testing-progress.md

@@ -2244,3 +2244,21 @@ git diff --check
 - 发布后以字节级扫描复核49条签名，非法UTF-8为0；两个目标ID均精确恢复为hex `e38090e888aae5a4a9e4bfa1e681afe4bfa1e8afbae7bd91e38091`（`【航天信息信诺网】`）。生产Prisma真实执行签名、报备任务、报备记录、待报备资料四类关联查询均成功，分别返回49、34、82、4条，不再触发P2039/22021。
 - API/Gateway health、外部首页、运营登录页、客户端登录页和外部API health均返回HTTP 200；Redis PONG，`gateway.submit.commands`为`pending=0、lag=0`，7个通道TPS权威配置存在。两个active上游通道均为`connected/currentConnections=1`；disabled通道的一条`connected/1`仍是2026-07-09历史状态残留，本次启动没有把它作为活动通道恢复。
 - 部署后API日志新增P2039/22021为0，Nginx中企业签名及相关报备接口新增5xx为0。应用内Browser因Chrome标签被另一Codex会话占用且控制连接超时，未完成登录态页面交互验收；本次以真实NestJS所用Prisma关联查询、PostgreSQL字节扫描和Nginx/API日志作为后端修复证据，不虚报浏览器交互通过。未发送短信，未审核、删除、充值、改密或修改其他生产业务数据。
+
+## 2026-07-23 预发布运营商区分规则同步（配置变更，未提交、未部署代码）
+
+- 在线证据以华为云2026年2月《消息&短信》号码规则为主，并以工信部关于`190/197/196/192`公众移动通信网网号核发信息交叉核对。规则覆盖三大基础运营商、移动转售号段及必要的上网卡/物联网/卫星前缀；按用户明确要求将中国广电`192`归入中国移动路由。
+- 变更前预发布`PhoneCarrierRule`有30条，存在`190`重复、移动`195`仅覆盖`1951—1952`、电信`191/193`等缺失。完整PostgreSQL及原规则CSV已备份至`/opt/cmpp-platform/backups/config/20260723-164357-phone-carrier-rules`；数据库备份SHA-256为`239c4c669d55e8ccf6bfc5458e92fab507e1af8cb928e7f4ace5cd7f53c1e6f1`，规则CSV SHA-256为`8e437138f0e1a526519b01c6ddc4e95ce58e1a76fb623dc2a3ab0f6616630e86`，两者权限600且gzip校验通过。
+- 使用单个PostgreSQL事务锁定并原子替换规则，最终30条全部active：移动12条、联通9条、电信9条。`19200000000`唯一命中`mobile / ^19[2578]`，备注明确“含中国广电192，按业务要求归中国移动”。
+- 真实管理员验证码登录成功（201），`GET /api/admin/dictionaries/phone-carrier-rules?page=1&pageSize=100`返回200和30条；对68个基础、转售及新号段代表号码按发送服务同款JavaScript正则验证，全部唯一命中、0个错配，随后真实登出成功。首次验证误把凭据文件的`password=unchanged`当作密码产生一次401，未锁定账号、未修改规则，修正为已授权密码后通过。
+- 本次只修改预发布字典配置，不改代码、不重启服务、不发送短信，也不回写历史短信运营商。号段规则反映原始码号分配；携号转网后的当前签约运营商无法只靠前缀判断，若业务要求实时识别需另接MNP/HLR能力。
+
+## 2026-07-23 下游 CMPP UDH 长短信持久化重组修复（发布前验证）
+
+- 根因确认不是近期回归，而是既有下游入站链路从未实现重组：Gateway 将每个 CMPP Submit 的完整 `MsgContent`（包含 UDH）直接按 UCS2/GB18030 解码并逐片调用 NestJS，NestJS 因而把两片当成两条独立短信，控制字节污染首部签名匹配。此前台账通过的是“平台完整正文向上游拆分”和“上游 Deliver 长上行重组”，未覆盖“企业客户端已拆分的下游 Submit 重组”。
+- Gateway 新增标准 8 位 `05 00 03`、16 位 `06 08 04` UDH 解析，校验 `PkTotal/PkNumber` 与 UDH 总片数/片序号一致，先剥离 UDH 再按 `MsgFmt` 解码，并向 NestJS 传递引用号、总片数、片序号和编码。真实 CMPP2.0 TCP 回归确认两片均获得成功 SubmitResp，API 收到的片正文不含 UDH。
+- NestJS/Prisma 新增 `CmppInboundLongMessage`、`CmppInboundLongMessageSegment` 及 migration `20260723120000_add_cmpp_inbound_long_message_reassembly`。分组键包含应用、账号、Src_Id、目标号码、引用号、总片数和编码；使用 PostgreSQL advisory transaction lock 与同组同片唯一索引保证并发幂等。分片齐全前不创建批次/短信，齐全后按片序合并并只创建一条完整正文记录；持久化稳定 `messageId` 和第一片 `Sequence_Id`，支持乱序、重复片、冲突拒绝、进程重启恢复及超时转 expired。
+- 本地真实 PostgreSQL 16 已应用 62 条 migration，schema 最新。事务验证成功写入2片并按序拼成 `【测试】第一片第二片正文`，同组同片重复索引被唯一约束拒绝，验证事务最终回滚为0条残留。真实本地 NestJS API + PostgreSQL + Redis 调用两次入站接口后，分组为 completed、持久化2片、只创建1条主记录，完整正文和第一片 `Sequence_Id` 均正确；未启动 Go Gateway 上游连接，未发送真实短信。
+- 新增长短信相关 API 回归5项（合并、乱序/重复/冲突、处理中断恢复、主记录已落库后的幂等恢复、超时终止）和 Gateway 回归3项（8位UDH、16位UDH、真实CMPP2.0两片转发）。API发送链83/83、API全量24 suites/295项、Gateway `go test ./...`、API build、前端build、Prisma generate/validate/status均通过。`verify:phase8`首次与本地API并发时BullMQ为438.93 TPS而失败；关闭仅由本轮启动的API后单测为909.56 TPS，完整重跑为872.43 TPS并通过。前端仅保留既有约1.92MB单chunk告警。
+- 预发布两次测试正文使用的 `【深圳市合正物业服务有限公司】` 在该应用签名库中不存在；本次修复能消除UDH污染并完整重组，但不会绕过签名审核。部署后复测前需先按正常产品流程为应用配置并审核该签名/模板，或改用应用已有的审核通过签名。数据库升级只新增两张重组表和外键/索引；如必须回滚，应先停止新版本 API/Gateway，再删除子表和父表，未完成分片审计会丢失，既有短信主记录不受影响。
+- 发布前功能代码、迁移、回归测试和文档已完成并获用户授权提交、推送和部署；本节先保留发布前验证证据，实际提交、备份、migration、服务重启和发布后验收结果在部署完成后追加记录。