fix: harden channel retry attribution and operations UI

docs/system-functional-test-cases.md

@@ -3853,3 +3853,45 @@ npm run verify:phase8
 - `SMS-REVIEW-010`：点击号码数量后，通过真实后端分页查看手机号码、归属地、运营商和短信状态；号码搜索与10/20/50条分页正确，接口同时兼容`reviewTaskId`和批次`riskTaskId`关联。
 - `SMS-REVIEW-011`：客户端和CMPP待审核任务创建时短信记录保存`reviewTaskId`；人工通过后短信由`pending_review`转为`queued`并入队，人工驳回后转拒绝且执行既有资金释放，不能只更新审核任务。
 - `SMS-REVIEW-012`：升级前历史`pending_review`异常记录保持原样，不执行数据修复或短信补发；升级后新任务不再产生审核任务与短信状态不一致。
+## 2026-07-26 发送批次号与任务号命名用例
+
+| 用例编号 | 场景 | 预期结果 |
+|---|---|---|
+| TC-ID-NAME-001 | 查看运营端短信任务进度 | 列表、查询条件和详情均使用“发送批次号”，显示真实`SmsBatchTask.taskNo` |
+| TC-ID-NAME-002 | 查看客户端批量任务、首页和发送成功提示 | 统一使用“发送批次号”，不再出现“任务编号”或“批次编号” |
+| TC-ID-NAME-003 | 查看短信审核列表、详情和号码明细 | 显示真实`SmsSendTask.taskNo`并统一命名为“审核任务号”，可按该编号筛选 |
+| TC-ID-NAME-004 | 查看报备任务及报备记录 | 列表、筛选和详情统一使用“报备任务号” |
+| TC-ID-NAME-005 | 验证接口和数据库兼容性 | 仅修改展示文案，不改变现有ID、`taskNo`、关联关系或协议`Msg_Id` |
+## 2026-07-26 企业删除拦截提示用例
+
+| 用例编号 | 场景 | 预期结果 |
+|---|---|---|
+| TC-TENANT-DELETE-001 | 删除仍有启用或停用中应用的企业 | 后端拒绝删除，确认弹窗保持打开，并在弹窗内显示应用数量及先停用应用的原因 |
+| TC-TENANT-DELETE-002 | 删除请求处理中重复点击或关闭弹窗 | 确认、取消和关闭均被禁用，不产生重复请求 |
+| TC-TENANT-DELETE-003 | 删除无阻塞依赖的企业 | 删除成功后才关闭弹窗，并刷新企业列表 |
+
+## 2026-07-26 运营页面细节与通道重连用例
+
+| 用例编号 | 场景 | 预期结果 |
+|---|---|---|
+| TC-OPS-UI-001 | 查看企业签名及引流信息报备状态 | 运营商以中文显示，目标通道显示真实名称，不出现内部通道编号替代名称 |
+| TC-OPS-UI-002 | 查看较长的短信上行内容 | 内容列宽不被其他列挤窄，可展示最多三行，完整内容可在详情查看 |
+| TC-CHANNEL-RECONNECT-003 | 仅修改启用中通道的名称、单价、运营商或TPS | 保存成功且不创建连接中状态、不发送Gateway连接控制请求 |
+| TC-CHANNEL-RECONNECT-004 | 前端提交包含未变化连接参数的完整通道表单 | 按修改前后实际值判断，不发送无效重连请求 |
+| TC-CHANNEL-RECONNECT-005 | 修改网关地址、账号、连接数、窗口或心跳参数 | 保存后发送连接控制请求；停用/启用仍正确断开/连接 |
+| TC-SMS-RECORD-006 | 首次进入短信记录或点击重置 | 日期默认覆盖北京时间昨天和今天，并以该范围请求真实后端 |
+| TC-DOWNSTREAM-UI-007 | 查看包含多次投递的下游投递详情 | 每次投递按纵向时间线展示中文状态、时间、连接和ACK证据，窄屏无需横向滚动 |
+| TC-GATEWAY-UI-008 | 查看Gateway提交异常列表 | 标题、说明、总数、表格和分页层次清晰，不紧贴容器边框 |
+| TC-REPORT-SCOPE-009 | 检查本轮报表变更范围 | T-4未知转失败未实现，日报未知口径和历史数据保持不变 |
+
+## 2026-07-26 通道补发归因与发送详情用例
+
+| 用例编号 | 场景 | 预期结果 |
+|---|---|---|
+| TC-RETRY-ROUTE-001 | 直接签名短信在首通道失败，签名在同组备用通道已报备通过 | 使用短信记录`signatureId`选中备用通道；无需模板；日志记录开始、选择结果和尝试通道 |
+| TC-RETRY-ROUTE-002 | 模板短信在首通道失败，备用通道不可用或未报备 | 不创建伪补发；结构化日志记录失败原因、通道组和已尝试通道，不静默吞错 |
+| TC-SUBMIT-ATTR-003 | 同一短信先后经两个通道提交，旧尝试的聚合结果迟到 | Gateway携带原始`submitId`；API只更新对应`SmsSubmitRecord`，不覆盖当前尝试主记录 |
+| TC-SUBMIT-ATTR-004 | 滚动升级期间收到不含`submitId`的聚合或分片结果 | 唯一候选时兼容并告警；零个或多个候选时返回失败、写歧义日志且不批量更新 |
+| TC-SUBMIT-ATTR-005 | 两分片长短信在通道A失败后由通道B补发 | 每个分片结果归属正确`submitId`和通道；任一迟到结果不污染另一尝试 |
+| TC-SMS-DETAIL-006 | 查看先经富泷失败、再经铁布衫失败的历史短信详情 | “通道发送与回执”显示两次真实通道及各自分片回执，不把两行都显示为最终通道 |
+| TC-CHANNEL-GROUP-007 | 调整通道组成员顺序、优先级、权重或主备 | 操作日志保存修改前后有序成员、通道编号和名称，可还原短信发送时配置 |