perf(cmpp): add durable inbound fast path

docs/codebase-modularization-roadmap.md

@@ -1155,5 +1155,7 @@ global，不能错误归入client。`client-signature-*`、发送页、企业认
 - V3客户入站窗口只归`gateway/internal/inbound/`与项目内受控的`third_party/gocmpp`服务循环治理：API认证只返回应用窗口，inbound会话负责收紧窗口，协议服务循环负责受限派发和断线等待；不得把客户入站槽位与`submitworker`供应商槽位或`upstream`供应商窗口合并成同一并发计数。
 - V4供应商结果异步边界只归`gateway/internal/resultoutbox/`治理：`upstream`在每个真实分片SubmitResp后只调用持久化接口，`submitworker`只负责聚合结果入Outbox与命令ACK的原子边界，Outbox回调Worker独立控制API并发和PEL恢复。API的`SmsSubmitRecord.resultEventId`是跨重启持久幂等事实；不得把HTTP回调重新放回供应商连接池或Submit工作槽，也不得让Outbox承担业务计费、补发或状态机判断。
 - V5 API数据库往返优化仍归`send-inbound-entry`、`send-gateway-submit`和`risk-review`现有边界：入口应用快照沿稳定Facade显式传递，单条快速入队只接受已持久化ID和优先级，通用批量入队保留原查询与取消校验；默认规则并发单飞属于`RiskReviewService`内部完整性保障，不得在`SendChainService`新增第二套规则缓存，也不得把余额、频控状态或实际规则决策缓存进进程内存。
+- 500条/秒第一阶段把接收与业务处理边界固定在`CmppInboundSubmissionInbox`：`gateway/internal/inbound`只生成连接域内稳定请求键，`send-inbound-entry`只负责最小校验、Inbox持久化和稳定响应；`api/src/send-worker.ts`在独立进程内领取并调用既有发送链。领取事务不得包住风控、计费、路由、Redis或供应商调用，业务幂等事实必须落PostgreSQL，不能依赖进程内缓存或localStorage。
+- API进程角色固定为`CMPP_PROCESS_ROLE=api`，不启动发送Worker、Inbox Worker和周期扫描；`cmpp-send-worker`固定为`worker`并拥有自己的Prisma连接池和回环指标。后续扩容允许水平增加Worker实例，但不得复制HTTP控制器或绕过Inbox直接创建业务消息。
 - `api/src/infrastructure-monitoring/`是运营端监控聚合与固定阈值应用边界：只消费代码白名单 PromQL，并通过版本化 PostgreSQL 单例、promtool 校验和原子规则热加载管理数值阈值；Exporter安装、端口隔离、固定规则模板和权限仍归`tools/monitoring/`治理。
 - 活动告警已读也归该边界：Prometheus保留告警事实，Prisma仅持久化逐管理员、逐触发周期的阅读状态；全局布局只消费轻量未读汇总，不复制指纹、activeAt或用户隔离逻辑。