fix: close receipt delivery workflows

docs/testing-progress.md

@@ -2372,3 +2372,22 @@ git diff --check
 - Gateway重启后5条活动供应商通道有4条立即在线，“富泷物业-联通”首次鉴权失败并按数据库`nextReconnectAt=2026-07-24 12:59:31+08`自动慢重试；到13:00只读复核时5/5均为`connected/currentConnections=1/desiredConnections=1`，最近心跳持续刷新、`nextReconnectAt`与`lastError`清空。
 - 公网首页、运营登录、客户端登录和API health均HTTP 200，公网CMPP 17890 TCP连接成功。真实浏览器加载运营端登录页，标题正确、页面无横向溢出、控制台0条业务error/warn；因图形验证码保护，本轮未绕过登录，登录后通讯日志页面仍需下一次人工登录结合真实短信复测。
 - 发布后API/Gateway日志未出现panic、fatal、unhandled、exception、通讯遥测失败或`SMS message record not found`。本次未发送真实短信、未修改或回填`13127620092`历史业务数据；跨连接真实供应商回执和长短信两片最终聚合仍需下一次授权测试短信或自然业务回执验证。
+
+## 2026-07-24 运营端账户充值回执（本地未提交、未部署）
+
+- 运营端充值记录每行新增“查看回执”操作，弹窗直接使用真实`RechargeOrder`、企业信息及订单关联的`balanceAfterCents`，据此计算入账前余额；历史记录缺少可追溯余额时显示`-`，不使用当前账户余额或前端假数据补齐。
+- 回执左上只展示系统现有`/logo/logo1.png`真实Logo；展示入账状态、本次金额、企业名称和编码、订单号、入账时间、前后余额、入账方式与备注，适合客户截图留存。
+- “本次充值金额”采用实际精度：整数不显示小数，存在小数时移除末尾无效零；前后余额继续显示平台统一四位精度。正数显示“已入账”，负数冲正显示“已冲正”。
+- 金额边界验证结果：`10000.0000 → 10,000`、`10000.2500 → 10,000.25`、`10000.0001 → 10,000.0001`、负数冲正`-123.4500 → 123.45`，符合主金额按实际精度展示口径。
+- 使用Node.js v24.14.0执行前端TypeScript和Vite生产构建通过，保留既有约1.93MB单chunk/579.51KB gzip警告；`git diff --check`通过。首次由系统旧Node执行时Vite不支持`??=`且错误返回0，已明确排除，未将其计为通过。
+- 浏览器加载真实本地前端/API后进入运营登录页，页面标题正确、控制台0条error/warn；由于当前浏览器无有效会话且存在图形验证码，本轮未绕过验证码，登录后的“查看回执”点击与视觉验收仍需人工登录后补测。
+- 本轮按要求保持未提交、未推送、未部署；预发布仍运行既有版本，不包含充值回执功能。
+
+## 2026-07-24 长短信失败终态、自动双通道投递与企业侧通讯日志（发布前）
+
+- 预发布只读复核号码`18821203795`的消息`MSG-e4ded553-8f08-4f7d-85ae-06a30b163e86`：主记录保存首片上游消息号`736078096474128384`，第二片`736078096490905600`收到`undelivered/YL:1014`，首片无回执。原逻辑只按主记录首片消息号查提交记录，导致第二片虽写入分片审计，但被误判为非当前尝试，主记录卡在`submitted`且未建立最终下游投递。
+- 修复为优先通过`SmsMessageSegmentAudit.gatewayMessageId`取得该分片所属`submitRecordId/submitId/channelId`，再执行当前尝试判断。长短信任一分片明确失败即可沿既有补发、退款和最终回执链路使整条短信终态化，不等待缺失分片；供应商原始非成功码（包括`YL:1014`）保持原样，不增加码表。
+- HTTP和CMPP投递改为按接口能力自动派生：CMPP开通即建CMPP下游投递，HTTP开通且对应Webhook地址有效即建HTTP事件，两者同时开通时双投。运营端不再提供回执/上行投递方式选择，HTTP关闭时仍显示并允许维护两个Webhook地址，保存空地址会删除对应端点并停止该类HTTP推送。
+- Gateway补充企业侧真实`CMPP_DELIVER`发送成功/失败以及`CMPP_DELIVER_RESP`接收结果通讯日志，API白名单允许`platform_to_client + deliver_receipt/deliver_uplink`和`client_to_platform + deliver_resp`。通讯日志只描述真实协议报文；`CmppDownstreamDelivery`继续保存排队、发送、ACK、失败和重试业务状态，两者不合并。
+- 新增migration`20260724143000_derive_application_delivery_modes`，按当前CMPP/HTTP开通状态回填历史配置的派生模式，避免旧人工模式继续影响展示或参数复制。
+- 已完成定向回归：OpenAPI、短信配置和Gateway事件3 suites/67项通过；SendChain新增长短信非首片失败、仅HTTP投递和CMPP关闭3项通过；Gateway inbound全量通过并覆盖企业侧DELIVER/DELIVER_RESP日志。另一个会话的运营端账户充值回执源码和文档已一并纳入本发布分支，原工作区未覆盖。