test: verify CMPP send guards and channel retry

docs/testing-progress.md

@@ -3861,3 +3861,16 @@ git diff --check
 - 在客户CMPP连接保持在线期间，经测试机内部Gateway事件入口注入一条携带实际`messageId/channelId/phoneNumber`的上行事件。`SmsUplinkMessage`按messageId精确匹配原应用和下发记录，内容“主流程回归上行短信”；客户端捕获`registered=0`普通Deliver并返回ACK，`CmppDownstreamDelivery`最终uplink delivered 1。该步骤验证Gateway事件入口至API入库、匹配和客户下行Deliver/ACK；供应商到Gateway的原始CMPP Deliver解包由随后Gateway全量`go test ./... -count=1`和`go vet ./...`覆盖，本轮未伪称为真实供应商上行报文注入。
 - 客户连接上线时还收到历史pending回执补投，因此客户端汇总`receipts=283`不能作为本轮回执数量；本轮严格使用开始时间、专用号段、MessageId和数据库外键隔离，新增回执事实为2条、上行为1条。该现象是既有待投递恢复行为，不归因到本次新增短信。
 - 回归结束已把`920001`单价恢复为0并保存after快照；双Stream pending/lag均0，数据库0等待锁/0 idle in transaction，API/Worker/Gateway均active。真实消息、计费、回执、上行和操作日志保留审计，预生产未变更。
+
+## 2026-08-21 CMPP发送准入、频控、通道禁用与通道组补发专项复测
+
+- 本轮只在`100.93.204.60`测试环境、`qa-bell-alerts-tenant`隔离企业及`910001`至`920007`压测应用执行；供应商为`100.91.249.119:17900`本地模拟器，没有触达预生产或真实短信。每个用例仅发送1条，号码频控用例发送同号2条；判定采用本次MessageId对应的PostgreSQL消息、提交、频控和回执事实，不采用客户端重连时收到的历史积压回执数。
+- 签名审核拦截通过：`920002`签名临时从`approved`改为`pending`后，消息`MSG-eedf1831-7c2c-425c-98be-8a4befcc8446`最终为`failed/SIGNATURE`，错误为“短信内容未识别到已审核通过的签名”，供应商提交0条。签名状态已恢复。
+- 模板强校验通过：压测应用默认没有模板且`templateMismatchMode=direct_send`，因此先将`920003`临时切为`reject`模拟必须报备模板；消息`MSG-3d3bea6a-3de8-4052-8aae-3ed613736b2f`最终为`failed/TEMPLATE`，错误为“短信内容未匹配到已报备模板”，供应商提交0条。应用模式已恢复`direct_send`。
+- 余额不足通过：`920004`临时单价325、企业可用余额临时置0后，消息`MSG-aaeb23b1-b18b-4f6b-8b41-0e610d244e9b`按325计算并最终为`failed/BALANCE`，供应商提交0条。应用单价已恢复0，账户余额/授信已恢复`16142576/0`。
+- 企业应用禁用/删除通过：分别关闭`interfaceEnabled`、把应用状态改为`inactive`和`deleted`时，客户CMPP登录均返回状态码3并断开，未进入提交阶段；恢复后`920005`为`active/interfaceEnabled=true`。企业禁用/删除通过：企业状态分别为`inactive`和`deleted`时，`920006`登录均返回状态码3；企业已恢复`active`。
+- 号码频次通过：为`920007`临时建立5分钟1条的应用级规则，同号`13800310000`第1条真实提交并`delivered`，第2条`MSG-40004fe5-21e0-41f2-8bc4-388d00ec6b2d`最终为`failed/RISK`、供应商提交0条；命中记录为阈值1、实际2。临时规则已删除，命中历史作为测试审计保留。
+- 通道签名报备拦截通过：将`910001`签名在移动主备两通道的报备任务临时改为`pending`后，消息`MSG-2c52fdc8-bc42-4287-a325-6780781ee2a3`最终为`failed/ROUTE`，错误为“无已报备通过且在线的可用通道”，供应商提交0条；2条报备任务均已恢复`approved`。
+- 通道禁用行为通过：仅禁用`LGST-M-P`时，消息`MSG-fc4a6384-3dfd-4252-bc5b-855e4e881a1a`自动选择`LGST-M-B`并`delivered`；主备同时禁用时，消息`MSG-5bf5960f-cfc1-4409-a6bc-80e6969ad827`最终为`failed/ROUTE`且供应商提交0条。两通道均已恢复`active`。
+- 通道组补发通过：模拟`LGST-M-P/SUP001`对消息`MSG-3c2ad6ea-9b45-435c-8833-7dbf7bf28ebd`返回Submit结果码8，首条提交记录为`rejected`；平台随后在`LGST-M-B`创建带`retryOfSubmitRecordId`的第二条提交，状态`accepted`，消息最终`delivered`。模拟器已恢复普通配置，6条通道连接均为`connected`。
+- 最终恢复审计：API及API/Worker/Gateway/PostgreSQL/Redis/MinIO服务健康；10个隔离应用全部`active`、接口全部开启、单价均0、模板模式均`direct_send`；10个签名审核/汇总报备均通过，60条签名通道报备任务全部`approved`；6个LGST通道全部`active/connected`；临时风险规则0条；Inbox仅有`completed`状态；专项窗口Worker严重错误筛查0条。