docs: diagnose paid single-tenant throughput ceiling

docs/phase-5-gateway-capacity-expansion-plan.md

@@ -491,3 +491,19 @@ API 必须返回逐事件结果，而不是只有整批成功或失败：
 直推领取修复后另执行100 TPS正价复验：999/999，P50/P95/P99=54/102/179ms；999个唯一MessageId、999次非补发首提在12.488秒完成（80.00 TPS）。972条已产生最终回执的投递全部ACK，生命周期尝试972、重复0、最大尝试1。计费998条：995 charged、3条供应商最终失败后refunded；1条RISK在供应商前失败且未计费。27条模拟器no-receipt保持submitted，不是队列丢失。Inbox、Submit Outbox、下游pending/dispatching/awaiting_ack、未授权锁和idle transaction最终均为0。
 
 最终结论分两种口径：客户入口SubmitResp受理已通过200 TPS冲击；完整供应商首提天花板约95 TPS。测试环境建议稳定限速70 TPS，保留约25%以上端到端余量；不将入口200 TPS宣称为供应商200 TPS。按用户要求，7个测试应用单价保持325，^1380028/^1300028/^1890028三条临时号段规则保留，原100.91.249.119/32和新增127.0.0.1/32白名单均保留，未做测试后删除或归零。
+
+## 14. 95 TPS天花板定向诊断
+
+100/150 TPS正价复验确认，Gateway的6条连接和192个窗口没有饱和；150档连接等待仅0.006ms、供应商RTT约13.761ms、窗口峰值10，命令Stream lag峰值27。真正的平台内排队发生在耐久Inbox之后、BullMQ发送之前的独立CMPP入站工作流。
+
+当前7个压测应用全部归属同一企业。尽管工作流配置为并发96、批次64，泵在一批完成后立即领取当时已有记录，100/150档实际平均批次仅5.84/9.79条，导致同一企业的日限、号码频控、消息持久化和正价账户冻结被大量小事务重复执行。150档Inbox完成延迟P50/P95为3.779/5.620秒，1498条首次供应商Submit用15.547秒完成，即约96.35 TPS；因此当前约95 TPS应定义为“单企业正价完整首提上限”，不能定义为多企业平台总上限。
+
+下一阶段优先级：
+
+1. 为入站工作流增加按企业分组的有界微批，目标批次32～64、最大等待20～50ms；
+2. 不同企业允许并行，同企业账户冻结保持串行和幂等；
+3. 继续合并配额、频控、消息及冻结流水的集合事务；
+4. 分别验证单企业100/150 TPS，以及至少两个独立企业合计200 TPS；
+5. 只有单Gateway资源被实测打满后才启动多Gateway P2。
+
+诊断还发现Outbox原生SQL使用`CURRENT_TIMESTAMP`，与Prisma UTC时间混用时会产生8小时审计偏差。该问题不影响本次吞吐和队列排空结论，但必须在下一次代码改造中统一为UTC并回归租约、重试和发布时延。