perf: batch CMPP inbound workflow processing

docs/testing-progress.md

@@ -3817,3 +3817,10 @@ git diff --check
 - 仅在测试环境连接总预算内设置API/Worker池48/32、Inbox业务槽96、BullMQ发送槽96、Gateway Submit槽128、结果Outbox槽32和客户入站上限128；代码默认值未改变，PostgreSQL`max_connections=100`仍保留至少20条非业务池余量。修复后1条/秒低负载9/9受理、P95=41ms，Inbox与短信主记录均9条且MessageId唯一，双Stream归零。
 - 正式100条/秒30秒档生成2998条，2998/2998成功，零拒绝、零节流、零连接错误，P50/P95/P99=`34/79/128ms`；相较第一阶段100条/秒P95=147ms，合并SQL在更高Worker竞争下仍降低入口尾延迟。数据库2998条Inbox全部completed、2998条短信主记录及唯一MessageId完全对账，Inbox从首条创建至末条完成约52.1秒，折算约57.5条/秒。
 - 该档未通过“完整处理100条/秒”停止线：全部为移动号码并只走`LGST-M-P`主通道，最终产生3863次供应商尝试，其中accepted3118、rejected78、timeout667；回退通道接受846次。命令Stream和结果Outbox从首条接收至最终0/0约136秒，按2998条业务短信折算约22.0条/秒；最终消息delivered2797、failed70、submitted131。高峰期间API后台协议日志、连接状态和待投递查询出现超时，说明提高Worker/Outbox槽后共享API/数据库回调仍受争用。因100档完整链已经失败，按阶梯停止线没有继续200/500档，不能宣称完整500条/秒达标。
+
+## 2026-08-21 完整处理500条/秒第三阶段：业务Worker批处理与数据库竞争治理（实施中）
+
+- 接管复核：本地`HEAD=57192b7586b1e2c14f2edf0633d2d35936352879`、`origin/main=c4f36fc50d7906dfb2f97c881e9ea43c6a64c370`，ahead 15；测试环境标记`f4560479...+workspace.p2fix.51553e0d5555`，预生产标记`433b2ee5...+gateway-v2.cd7bb8d05e7b`。测试机API/Worker/Gateway/PostgreSQL/Redis/Nginx/Prometheus均active，92条migration、数据库6连接/无idle in transaction/无未授予锁，Inbox和双Stream均排空；预生产仅只读核验，未修改。
+- 当前实现把Worker按默认64条组成有界业务批次：批次共享应用、模板、签名、黑名单、风控规则和敏感词只读快照；日限额按applicationId固定顺序锁定并为每条请求写独立预留；唯一号码频控按应用在短事务批量更新并逐条持久化决定；正常零计费单号码的任务、API请求和消息三表在一个短事务批量创建，再以MessageId作为BullMQ Job ID批量入队和逐条结算Inbox。
+- 正单价、同号重复、业务拒绝、人工审核、歧义匹配、既有消息和其他异常保留原逐条状态机。批量路径任一步失败会使用稳定日限/频控键、确定性任务号/请求号、MessageId和队列Job ID逐条恢复；Redis发布不包在数据库事务中。新增固定阶段`worker_claim/reference_preload/daily_quota`并保留`risk_frequency/message_persist/queue_publish`。
+- 当前本地API正式TypeScript编译通过；RiskReview、PhoneFrequency、SendChain专项3套145项通过。尚未提交、建立本次恢复资产、部署或压测；后续结果必须按smoke→100→200→300→500停止线补记，且零计费批量结果不得外推为付费链路吞吐。