perf: expand gateway capacity and prevent receipt replay

docs/first-version-development-requirements.md

@@ -2148,3 +2148,14 @@
 - Gateway供应商事件必须与主API控制面隔离：Submit结果、分片结果、回执、上行、受限协议日志和死信进入仅绑定回环地址的独立进程及独立有界PostgreSQL池；连接状态控制继续进入主API。客户HTTP Webhook使用异步队列Worker，不能在Gateway事实回写请求中同步调用客户地址。
 - 独立回调进程不得加载运营/计费管理Controller，不得经Nginx或公网暴露；部署必须验证回调健康、池上限、回环监听、事件URL和控制URL。回调服务先于Gateway启动/重启，回调失败应由既有结果Outbox恢复且不得重复处理、重复扣费。
 - 本阶段测试环境以正价325金额单位验证：50 TPS档必须同时满足客户端受理、非补发首次供应商Submit不低于50条/秒、MessageId/submitId/Outbox唯一、账单笔数和金额一致、Inbox/Outbox/Stream排空及数据库无持续锁等待。零计费结果不得作为付费链路容量结论。
+
+## 单 Gateway 容量扩展第五阶段（2026-08-25）
+
+- 单个供应商通道必须支持1～8条连接、每连接1～64窗口，并在API校验、Gateway控制入口和实际运行状态三层执行相同边界；扩容需串行预热，缩容需先停止分配并等待在途完成，不能因改配置直接丢弃在途映射。
+- Gateway协议摘要日志不得在Submit热路径同步写数据库或逐条HTTP回调。成功事件可确定性采样，拒绝、超时、断链和非零结果必须全量进入Redis Stream，由独立有界数据库池批量持久化；ACK只能发生在数据库提交后。
+- Submit结果、分片结果、回执、上行和死信应由结果Outbox聚合为最多100条、默认50条的回环HTTP批次。API必须逐事件返回accepted/retryable/errorCode；整批传输失败重放，单个非法事件不得拖累其他事件，事件必须依赖稳定幂等键。
+- Gateway必须暴露连接数、配置/在途窗口、批量回调请求/事件/重试/死信和协议日志发布/采样/错误/Stream长度指标。回调、日志Worker和主API数据库池必须独立有界，PostgreSQL总连接预算不得因扩容失控。
+- 正价容量仍以非补发首次供应商Submit和全链路对账为准。2026-08-25测试机实测20/30/50档稳定，70档出现4秒级P95且未达到目标，故当前单Gateway发布建议上限为50 TPS；100/150/200按停止线未执行。多Gateway租约、fencing和分片属于P2，仍未实施。
+- Gateway拉取待投递回执必须按账号进程内单飞，API必须用FOR UPDATE SKIP LOCKED将pending原子领取为带租约的dispatching；未实际发送的领取必须无损释放，租约过期可恢复。SubmitResp后只能合并调度账号级刷新，不得每条并发扫描同一批pending记录。
+- API新建回执后的直推与Gateway恢复拉取必须共享同一dispatching + claimId所有权；直推未抢到记录时必须退出，不得与恢复路径各发一次。ACK超时定时器必须在ACK注册锁内完成指针赋值，避免极短截止时间下的竞态。
+- 2026-08-25修复后正价阶梯客户入口20/30/50/70/100/150/200 TPS均零拒绝、零节流、零连接错误；完整供应商首提在150/200冲击档分别约94.86/92.24 TPS，显示端到端容量天花板约95 TPS。二次直推领取修复后100 TPS正价复验为999/999、P95/P99=102/179ms、999次999个唯一首提在12.488秒完成（80.00 TPS），972条已形成终态回执的下游投递生命周期尝试次数恰为972、重复0、最大1。生产建议仍保留容量余量，建议限速70 TPS，不将客户SubmitResp受理200 TPS误作完整供应商TPS。