fix: harden dependencies and downstream delivery

docs/system-functional-test-cases.md

@@ -36,6 +36,7 @@
 | TC-ADMIN-TEMPLATE-0715-06 | P1 | 将光标置于模板中间并插入推荐/自定义变量 | 变量在光标或选区处插入，原选区被替换，光标停在变量后；运营端和客户端一致。 |
 | TC-ADMIN-RECORD-0715-07 | P1 | 查看桌面/窄屏短信记录及失败详情 | 卡片不产生页面横向滚动，信息分组清晰；失败原因独立突出；详情仍读取真实 submit、receipt 和分片审计 API。 |
 | TC-ADMIN-MISC-0715-08 | P2 | 查看签名引流信息、零待审核通知和充值弹窗 | 使用“引流信息”标题且无提交时间；0 为黑字灰底；充值弹窗无操作人字段。 |
+| TC-ADMIN-NOTICE-0715-09 | P1 | 制造下游投递告警后打开右上角“待审核任务” | 待审核总数和菜单仅包含五类真实审核任务，不出现“下游投递告警”；运营看板和下游投递页仍展示下游告警。 |
 | 客户 | 正常客户、停用客户、欠费客户、未认证客户、跨租户客户、客户联系人和开票资料。 |
 | 导入文件 | UTF-8 CSV、GBK CSV、TXT、超 20 MB 文件、含空行/重复/非法号码/非法字符文件。 |
 | 非法内容 | 控制字符、emoji、换行、不可见字符、超长变量、签名外置内容、敏感词内容。 |
@@ -1361,14 +1362,14 @@
 - 优先级：P1
 - 前置条件：真实 `CmppDownstreamDelivery` 中准备阈值内/外的 `pending`、未超时/已超过 `ackDeadlineAt` 的 `awaiting_ack`、最近窗口内/外的 `failed/unconfirmed/rejected` 及正常 `delivered` 记录，且覆盖多个应用。
 - 步骤：
-  1. 访问运营端 Dashboard 和右上角通知区域。
+  1. 访问运营端 Dashboard、下游投递记录页和右上角待审核通知区域。
   2. 调用真实 `/api/admin/operations/dashboard/statistics`，核对返回的下游投递告警聚合。
-  3. 点击“下游投递告警”通知，跳转到下游投递记录页进一步筛查。
+  3. 打开右上角“待审核任务”，核对菜单和总数只包含审核业务。
 - 预期结果：
   - Dashboard 返回真实 `downstreamDeliverySummary`，至少包含 `pending/failed/delivered/stalledPending/stalledAck/recentFailed/alertCount`。
   - `alertCount` 精确等于“超阈值 pending + 超时 awaiting_ack + 最近窗口内 failed/unconfirmed/rejected”，阈值内 pending、未超时 awaiting_ack、历史失败和 delivered 不计入。
-  - 侧栏/首页的“下游投递告警”数量与下游投递 Dashboard 在同一筛选范围下一致，不是前端写死值。
-  - 点击通知后可以进入真实下游投递记录页继续处理。
+  - 运营看板的“下游投递告警”数量与下游投递 Dashboard 在同一筛选范围下一致，不是前端写死值。
+  - 右上角“待审核任务”不出现下游投递告警菜单或数字；下游异常从运营看板或下游投递记录页进入处理。
 
 ### TC-GW-018 下游投递 Dashboard 聚合视图
 
@@ -3254,8 +3255,9 @@ npm run verify:phase8
 | TC-BILLING-009 | 无权限用户、审核员、管理员分别执行充值；大额人工充值不走审批。 | 权限不足被拒绝并写失败日志；有权限用户确认后立即入账；不产生 pending 审批态；充值订单、账户余额、流水和日志同步完成。 |
 | TC-BILLING-010 | 余额不足发送失败，人工充值后重试发送并模拟 delivered。 | 充值前不扣费；充值后发送成功；冻结、扣费、短信计费记录完整；reconciliation diff 为 0。 |
 | TC-BILLING-011 | 分别准备 `余额+授信` 为正数、0 和负数的账户，使用相同短信费用发起发送。 | 和为正数时允许发送；和为 0 或负数时提示余额不足。判断公式为 `balanceCents + creditCents > 0`，与本次费用和套餐无关。 |
-| TC-BILLING-012 | 已扣费短信收到最终失败回执；另一个未提交成功任务只释放冻结。 | 前者只生成一条 refunded 流水并计入“今日返还”；重复回执不重复退款；后者的 released 流水不计入“今日返还”。 |
+| TC-BILLING-012 | 已扣费短信收到最终失败回执；另一个消息在提交前失败并释放冻结；另准备一笔任务冻结转扣费时的批次级释放。 | 最终失败只生成一条 `refunded` 并计入“今日返还”，重复回执不重复退款；提交前失败生成 `released + relatedType=sms_message_record` 并计入“今日返还”；冻结转扣费的 `released + relatedType=sms_batch_task` 属于内部转换，不计入“今日返还”；客户端和运营端当日金额一致且保留三位小数。 |
 | TC-BILLING-013 | 准备已提交扣费但 72 小时完全无回执的 `submitted` 短信，以及有 `UNKNOWN` 回执且超过 72 小时的短信；启动 API 定时扫描并模拟重复扫描。 | 两类短信都转为 timeout 并退款；任务进度刷新；同一短信只退款一次；定时扫描默认启用且每 5 分钟执行。 |
+| TC-SEC-006 | 安装 API 生产依赖并执行 `npm audit`；使用缺文件、多文件、超大文件、超量字段和正常单文件调用认证后的 multipart 上传接口。 | NestJS/Multer/Hono 已升级或锁定到修复版本，生产依赖 audit 为 0；接口只接受一个不超过 20MB 的文件，并限制字段、part、字段名、字段值和 header pair 数量；异常请求返回受控 4xx，正常文件仍写入真实 MinIO 和 `FileObject`。 |
 
 ### 17.6 系统日志细化
 
@@ -3370,3 +3372,5 @@ npm run verify:phase8
 | TC-GW-ACK-003 | 在企业应用中分别关闭“回执自动重试”和“上行短信自动重试”，各制造一次 ACK 超时，再重新开启并创建新投递。 | 关闭只影响对应类型的新投递策略快照；离线后的首次投递仍会在重连时执行；已写出未确认的记录不自动重发；重新开启后新记录按退避策略重试。 |
 | TC-GW-ACK-004 | 对 `unconfirmed/rejected/failed/delivered` 记录执行单条和批量手工重投。 | 页面提示重复处理风险并二次确认；真实调用 Gateway；`awaiting_ack` 不允许并发重投；重发复用同一业务 Msg_Id。 |
 | TC-GW-ACK-005 | 客户 Submit 后由业务校验立即生成失败回执，并覆盖在线即时投递、Gateway 重启后恢复投递；另模拟客户端对 `Msg_Id=0` 返回 Result=0。 | 客户收到的第一个响应包必须是对应 `CMPP_SUBMIT_RESP`，之后 Deliver 的 `Msg_Id` 非 0 且与 SubmitResp 完全一致；重启后根据持久化 Submit Sequence_Id 重建同一 Msg_Id；Result=0/Msg_Id=0 不得写为 delivered。 |
+| TC-GW-ACK-006 | 对一条 Gateway 已丢失原消息映射且 payload 缺少 `submitSequenceId` 的历史状态回执执行人工重投；另对字段完整但客户离线的记录重投。 | 缺少序列号的记录由 Gateway 返回 `retryable=false/MISSING_SUBMIT_SEQUENCE_ID`，NestJS 立即终结为 `failed` 并保存明确原因；客户暂时离线的记录返回 `retryable=true/CLIENT_DISCONNECTED`，按次数上限和指数退避继续处理，不得无限保持 `retryCount=0`。 |
+| TC-GW-ACK-007 | 构造一条从未重投且 pending 超过 72 小时的记录，以及一条人工重投后尚未满 72 小时但原 `createdAt` 很早的记录，执行自动扫描并查看告警。 | 第一条自动转为 `failed/queue_timeout`；第二条仍保持 pending，终结时间和 10 分钟积压告警均从 `lastRetriedAt` 重新计算，刚重投后不立即告警。 |