test: verify CMPP send guards and channel retry

docs/system-functional-test-cases.md

@@ -4791,3 +4791,22 @@ npm run verify:phase8
 执行记录（2026-08-21）：`P4-001/003/004/005/008/009/010`已由自动化、真实PostgreSQL账务、六通道隔离模拟器及配置回读覆盖；正价smoke通过。`P4-006`在100条/秒档2999/2999入口受理，但最后供应商提交耗时167.991秒，完整链约17.85条/秒，判定失败并按停止线未升200/300/500。`P4-002/007`本轮未追加专项压力场景，保留待测；临时单价、主备和号段规则已恢复，财务流水保留审计。
 
 主流程回归记录（2026-08-21）：停止继续性能优化后，以2条单价325的隔离CMPP短信验证接收、发送、供应商SubmitResp、最终回执和计费，Inbox/Submit/Receipt/Message/Billing均2条闭合，冻结/释放/扣费金额均650。另以实际MessageId注入1条测试机内部Gateway上行事件，上行精确匹配且客户CMPP普通Deliver/ACK最终delivered；Gateway原始CMPP上行解析由全量Go测试和vet通过补充覆盖。临时单价已恢复为0，队列和数据库稳定，允许进入Git发布检查。
+
+## CMPP发送准入与通道路由专项（2026-08-21）
+
+| 用例ID | 场景 | 步骤 | 预期 |
+| --- | --- | --- | --- |
+| TC-CMPP-GUARD-001 | 签名未审核 | 将隔离应用签名改为待审核后提交1条带该签名短信 | 消息以`SIGNATURE`失败，生成客户失败回执，供应商提交0条 |
+| TC-CMPP-GUARD-002 | 模板未报备 | 应用启用模板强校验且不存在匹配的已审核模板时提交1条 | 消息以`TEMPLATE`失败，供应商提交0条；`direct_send`应用不应误套用此断言 |
+| TC-CMPP-GUARD-003 | 余额不足 | 设置正单价并使余额加授信小于本条金额后提交 | 消息以`BALANCE`失败，不冻结成负数、不进入供应商提交 |
+| TC-CMPP-GUARD-004 | 应用接口关闭 | 关闭企业应用接口并发起CMPP登录/提交 | CMPP登录被拒绝，不能新增入站消息或供应商提交 |
+| TC-CMPP-GUARD-005 | 应用禁用或删除 | 分别将应用状态置为`inactive`、`deleted`后登录 | 两种状态均在认证阶段拒绝，恢复后可重新登录 |
+| TC-CMPP-GUARD-006 | 企业禁用或删除 | 分别将企业状态置为`inactive`、`deleted`后由其应用登录 | 两种状态均在认证阶段拒绝，不影响恢复后的应用配置 |
+| TC-CMPP-GUARD-007 | 单号码频次 | 配置应用级5分钟阈值1并连续向同号提交2条 | 第1条正常发送，第2条以`RISK`拦截；命中记录阈值/实际值正确且第2条供应商提交0条 |
+| TC-CMPP-GUARD-008 | 签名未在候选通道报备 | 将签名在路由组所有候选通道的运营商报备改为未通过后提交 | 消息以`ROUTE`失败，供应商提交0条；任一已报备在线候选仍存在时不得误拦截 |
+| TC-CMPP-GUARD-009 | 主通道禁用 | 禁用通道组主通道、保留已报备且在线的备通道后提交 | 新消息不选禁用主通道，自动选择备通道并可最终送达 |
+| TC-CMPP-GUARD-010 | 通道组全部通道禁用 | 同时禁用组内主备通道后提交 | 消息以`ROUTE`失败，供应商提交0条，不向已禁用连接发送 |
+| TC-CMPP-GUARD-011 | 主通道拒绝后组内补发 | 让主通道返回非0 Submit结果，组开启补发且备通道在线/已报备 | 首次提交`rejected`；第二次提交指向未尝试备通道并关联`retryOfSubmitRecordId`，接受后按真实回执进入终态 |
+| TC-CMPP-GUARD-012 | 配置恢复审计 | 每项测试后回读企业、应用、余额、签名、报备、通道、连接和临时规则 | 所有临时配置恢复原值，服务健康、队列无异常状态，操作和测试证据可追溯 |
+
+执行记录（2026-08-21，测试环境）：`TC-CMPP-GUARD-001`至`012`全部通过。入口采用耐久异步受理，因此业务拦截用例的SubmitResp仍可为0；最终结论以本次MessageId对应的消息错误码、供应商提交数及客户失败回执为准。通道组补发实测主通道结果码8、备通道accepted、消息最终delivered；全部临时配置已恢复。

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条。