feat: densify sms records and improve uplink matching

docs/system-functional-test-cases.md

@@ -234,9 +234,10 @@
   2. 按手机号和时间查询。
   3. 查看上行关联下发记录。
 - 预期结果：
-  - 展示上行内容、接入号、接收时间。
-  - 可展示匹配到的下发 messageId。
-  - 未匹配上行仍可查询，状态或关联为空。
+  - 展示上行内容、接入号、接收时间、上行网关消息 ID、匹配状态和匹配说明。
+  - 后端已通过接入号或手机号时间窗匹配时，即使上行事件没有关联平台 `messageId`，详情仍直接展示响应中嵌入的真实下发记录及其平台 `messageId`。
+  - 上行网关消息 ID 与关联平台消息 ID 分栏展示，不把供应商 MO `Msg_Id` 误作历史 MT Submit 消息 ID。
+  - 未匹配或多候选上行仍可查询，并显示真实状态；多候选提示联系运营人员认领。
 
 ### TC-CLIENT-010 用户管理与企业管理员唯一性
 
@@ -1139,11 +1140,16 @@
 ### TC-SEND-008 上行短信匹配
 
 - 优先级：P1
-- 步骤：模拟带 messageId 的上行事件。
+- 步骤：
+  1. 模拟带平台 `messageId` 的兼容上行事件。
+  2. 模拟真实供应商 MO：仅带独立 `gatewayMessageId`，不带历史平台 `messageId`，并分别制造接入号唯一匹配、手机号 72 小时唯一匹配和多候选场景。
+  3. 打开客户端和运营端详情。
 - 预期结果：
   - 创建 SmsUplinkMessage。
-  - tenantId 可通过 messageId 关联。
-  - 客户端和运营端均可查询。
+  - `gatewayMessageId` 原样持久化；兼容事件仍可通过平台 `messageId` 精确关联。
+  - 不带平台 `messageId` 时按接入号、手机号 72 小时窗口执行匹配；唯一结果写入 `tenantId/applicationId/messageRecordId`，多候选保留为 `ambiguous`。
+  - 客户端和运营端均可查询；详情优先使用 API 响应内嵌 `messageRecord`，不因 `messageId` 为空误报“无法匹配”。
+  - 运营端对已匹配或已认领应用显示“加入应用黑名单”，确认后调用真实企业应用黑名单 API；客户端保持只读。
 
 ### TC-SEND-009 未匹配上行短信入库
 
@@ -1151,6 +1157,7 @@
 - 步骤：模拟不带 messageId 或匹配不到下发记录的上行事件。
 - 预期结果：
   - 上行短信仍入库。
+  - 供应商 MO `gatewayMessageId` 与平台 `messageId` 分别保存，不能用前者伪造后者的关联。
   - tenantId 可为空。
   - 运营端可查询并人工判断。
 
@@ -4890,3 +4897,15 @@ npm run verify:phase8
 | TC-CMPP-PHASE5-018 | 同连接并发状态回调 | 同一connectionId的connected与submit并发时幂等upsert且保持在线；不同connectionId超过cmppMaxConnections仍403，不能误断当前连接或漏SubmitResp |
 
 执行记录：按企业微批发布后，单企业100 TPS为999/999响应、P95/P99=`243/466ms`、首次供应商Submit=`95.85 TPS`；单企业150 TPS冲击为1498/1498、`83/117ms`、首次Submit=`122.87 TPS`；双企业200 TPS冲击为1999/1999、`148/287ms`、首次Submit=`129.39 TPS`。三档最终有效运行均零拒绝、零节流、零连接错误，价格均325。双企业档账务1988 charged/646100、11 refunded/3575；2145个Submit/Outbox唯一，1950条终态回执投递1950次、重复0，973条离线pending通过零发送客户端排空。多Gateway P2未实施。
+
+## TC-ADMIN-SMS-RECORD-DENSITY 运营端短信记录高密度列表（2026-08-27）
+
+| 用例ID | 场景 | 预期 |
+| --- | --- | --- |
+| TC-ADMIN-SMS-RECORD-DENSITY-001 | 打开短信记录搜索区 | 企业、应用、提交日期、手机号码、运营商、短信内容、通道、发送状态、是否含引流信息9项条件均保留，不能新增、删减或合并 |
+| TC-ADMIN-SMS-RECORD-DENSITY-002 | 在桌面与窄视口查看搜索区 | 仅控件宽度和布局响应式变化，9项条件、查询和重置行为不变，无控件覆盖或截断 |
+| TC-ADMIN-SMS-RECORD-DENSITY-003 | 查看包含单分片和多分片的短信记录 | 列表按日期分组；提交与回执分别显示日期和时分秒；计费列同时显示真实金额、分片数和字数；列表不显示“已补发”标签 |
+| TC-ADMIN-SMS-RECORD-DENSITY-004 | 点击任一行最右侧箭头 | 继续打开既有发送详情弹窗，原有短信内容、通道发送与回执、状态信息及分片补偿审计保持不变 |
+| TC-ADMIN-SMS-RECORD-DENSITY-005 | 使用真实本地API数据加载、查询、翻页和打开详情 | 页面非空、无异常遮罩，控制台无新增错误；数据仍来自原有真实API，不引入mock或localStorage业务数据 |
+
+执行记录：本地真实API/PostgreSQL渲染通过，9项条件全部存在，1/2分片均显示在计费列；右箭头成功打开原有详情弹窗，干净页面控制台日志为空。R11契约、前后端构建、159项API专项测试及Gateway全包测试/vet通过。