fix: reassemble inbound CMPP long messages

docs/system-functional-test-cases.md

@@ -1011,6 +1011,21 @@
   - 放入联通通道组的三网通道不能被移动号码选中。
   - route/trace 标明实际命中的三网通道。
 
+### TC-SEND-016A 预发布运营商号段规则完整性
+
+- 优先级：P0
+- 前置条件：运营商区分规则已按当前公开码号资料同步。
+- 步骤：
+  1. 读取真实 `GET /api/admin/dictionaries/phone-carrier-rules?page=1&pageSize=100`。
+  2. 使用移动、联通、电信基础号段及 `162/165/167/170/171` 等移动转售号段生成代表号码。
+  3. 使用 `190/191/192/193/195/196/197/198/199` 生成代表号码。
+  4. 对每个代表号码按发送服务相同的优先级和 JavaScript 正则逐条匹配。
+- 预期结果：
+  - 每个代表号码唯一命中一条 active 规则，不得重叠或漏配。
+  - `190/191/193/199` 归电信，`196` 归联通，`195/197/198` 归移动。
+  - 中国广电 `192` 按当前业务约定唯一归入移动。
+  - 测试结论仅代表原始号段分配规则，不把携号转网号码误宣称为实时运营商识别。
+
 ### TC-SEND-018 失败补发停止条件
 
 - 优先级：P0
@@ -1205,6 +1220,25 @@
   - CMPP 内部批次的详情、短信明细和取消请求均返回不可见/不存在，不泄露内部任务。
   - CMPP 短信仍完整出现在短信记录、提交、回执和账务链路。
 
+### TC-GW-006A 下游 CMPP UDH 长短信持久化重组
+
+- 优先级：P0
+- 前置条件：企业应用可正常 bind；已配置审核通过的完整签名和模板；NestJS、PostgreSQL、Redis 与 Go Gateway 使用真实本地或预发布链路。
+- 步骤：
+  1. 使用 CMPP2.0 和 CMPP3.0 分别提交一条两片长短信，分片正文使用 UCS2，首片携带签名；覆盖 8 位 `05 00 03` 和 16 位 `06 08 04` UDH。
+  2. 第一片提交后查询 `CmppInboundLongMessage`、`CmppInboundLongMessageSegment`、`SmsBatchTask` 和 `SmsMessageRecord`。
+  3. 乱序提交第二片，再重复提交内容和 `Sequence_Id` 完全相同的分片。
+  4. 使用相同引用号和片序号提交内容不同或 `Sequence_Id` 不同的冲突片。
+  5. 在全部分片已持久化、业务处理尚未完成时重启 API，再重放任一已存分片。
+  6. 只提交部分分片并等待超过 `CMPP_INBOUND_LONG_MESSAGE_TTL_SECONDS`，执行超时扫描。
+- 预期结果：
+  - Gateway 去除 UDH 后才按 `MsgFmt` 解码，NestJS 收到的每片正文不含 `05 00 03`/`06 08 04` 控制字节；每个合法分片均返回 `SUBMIT_RESP status=0`。
+  - 分片未齐全时只存在一条 collecting 分组和已收分片，API 返回稳定的分组 `messageId`，不得创建内部批次、短信主记录、计费或路由。
+  - 分片齐全后按 `segmentIndex` 唯一排序拼接，只创建一条完整正文 `SmsMessageRecord` 和一个内部批次；正文签名/模板识别针对拼接后的完整内容执行，`cmppSubmitSequenceId` 使用第一片 `Sequence_Id`。
+  - 乱序可完成；完全相同的重复片幂等复用原结果；冲突片返回明确 4xx/非零 SubmitResp，数据库唯一约束禁止同组同片序号出现两行。
+  - API 重启后从 PostgreSQL 恢复分组、分片、原 `messageId` 和第一片 `Sequence_Id`，不得重复创建主记录。
+  - 超时未齐分组转为 expired，保留分片审计但不创建短信主记录；后续相同引用号的新消息可建立新分组。
+
 ### TC-SEND-039 CMPP 模板不匹配短窗口聚合人工审核
 
 - 优先级：P0