perf(cmpp): reduce inbound database round trips

docs/system-functional-test-cases.md

@@ -4690,6 +4690,11 @@ npm run verify:phase8
 | TC-CMPP-PERF-V4-006 | Outbox有界指标 | 制造回调在途和积压后抓取Gateway metrics | 回调Worker configured/in_flight与真实槽位一致，Outbox pending/lag与Redis consumer group一致，指标不含手机号、消息、submit、企业、应用或通道标签 |
 | TC-CMPP-PERF-V4-007 | 双Stream发布后排空 | 完成一档隔离压测并等待异步处理结束 | `gateway.submit.commands`和`gateway.submit.results`均为`pending=0/lag=0`，结果Outbox成功事件已删除，无Gateway Submit死信；数据库业务数与客户端完全一致 |
 | TC-CMPP-PERF-V4-008 | V4阶梯容量复测 | 在V3相同隔离供应商模拟器与真实API/PostgreSQL/Redis/Gateway中依次执行10、20、30、40、50条/秒各60秒 | 对比V3的SubmitResp分位、供应商RTT、命令Stream、结果Outbox、API阶段和资源；任一档出现拒绝、连接错误、P95超过5秒、双Stream持续增长或服务异常立即停止升档 |
+| TC-CMPP-PERF-V5-001 | 入站应用快照复用 | 分别提交单号码、多号码和完整长短信，并统计`SmsApplication`查询 | 每次Submit入口只查询一次账号对应应用、企业和IP白名单；全部目标号码复用该已校验快照，应用/IP/模板/风控业务结果不变 |
+| TC-CMPP-PERF-V5-002 | 默认规则完整性检查单飞 | 同一API实例并发触发任务风控和号码频控，再在30秒内重复提交 | 并发调用共用一个检查Promise；默认5条规则完整时只执行一次聚合count，不再逐消息产生两轮各5次存在性查询；实际生效规则和频控状态仍逐消息读取 |
+| TC-CMPP-PERF-V5-003 | 默认规则缓存失效与恢复 | 让聚合检查失败后重试；另在缓存期后模拟缺失一条默认规则 | 检查失败立即清除缓存并允许下次重试；短TTL内只缓存完整性，TTL后发现缺失规则并按既有创建校验恢复，不缓存应用规则内容或业务判断 |
+| TC-CMPP-PERF-V5-004 | 已持久化单消息快速入队 | 创建CMPP单号码内部任务和消息，记录已知taskId、messageRecordId、queuePriority后进入队列 | BullMQ jobId仍为messageRecordId、attempts和优先级不变；不再回查刚创建的任务和消息，任务最终更新为queued；普通批量任务原通用入队路径保持兼容 |
+| TC-CMPP-PERF-V5-005 | V5隔离环境阶梯复测 | 发布到虚拟机测试环境后，以V4相同模拟器、连接数、8槽Outbox和10/20/30/40/50条每秒阶梯执行 | 对比V4的SubmitResp分位及`application_lookup/risk_frequency/queue_publish/complete_submit`阶段；数据库业务数、冻结/计费、双Stream排空和回执幂等保持一致，遇拒绝、连接错误、P95超过5秒或持续积压立即停止 |
 | TC-GLOBAL-ALERT-001 | 铃铛分域预警菜单 | 准备签名清退未读消息和安全待处置告警后点击右上角铃铛 | 弹层分开显示“签名清退预警”和“安全检测与封禁”，分别展示真实数量和摘要，角标等于两项之和 |
 | TC-GLOBAL-ALERT-002 | 预警菜单跳转 | 分别点击铃铛中的两个菜单项 | 签名项跳转`/admin/signature-retirement`，安全项跳转`/admin/security-detection`，弹层关闭且对应页面读取真实后端数据 |
 | TC-GLOBAL-ALERT-003 | 域间故障隔离与轻量轮询 | 分别让一个汇总接口失败并观察30秒轮询请求 | 失败域显示0且另一域数据保留；安全预警使用专用汇总接口，不调用完整overview、规则、代理状态或告警大列表 |