线上(测试机)现象:FRIDAY 推 med_emr_info 每小时整点重试,连挂 25 次,
对面收到 http 500 body={"code":90000,"msg":"request entity too large"}。

根因两层:
1. main.ts 从未显式设 body limit → 吃 body-parser 出厂默认 100KB。
   实测卡点 102,381B 过 / 103,405B 挂,正好 100KiB。
   网关 client_max_body_size 是 50M,不是它拦的(对面收到的是 PAC 的 JSON 封装)。
2. body-parser 的 PayloadTooLargeError 是裸 Error(非 HttpException),
   掉进过滤器的 500/90000 分支 → 对面按文档 §9.1 把 9xxxx 当"PAC 内部错误 →
   退避重试",于是整点重试永远重试不好,也看不出是自己包太大。

为什么病历先踩到:测试机实测 friday 已入库 payload 单行大小 ——
  emr 均 1453B / 峰值 2218B,diagnosis 均 1647B(带主诉/检查/处置/医嘱自由文本)
  appointment、encounter 均 405B
接入文档 §10 只约束"≤500 条/请求",没约束字节:500 条病历 ≈ 710KB,超默认值 7 倍;
连 405B 的预约行 500 条(≈198KB)也超 —— 雷对所有表都埋着,病历只是先踩到。

改动:
- main.ts: useBodyParser 显式设 10MB(json + urlencoded)。取 10MB 是因为它给
  500 条病历留了十几倍余量,又远低于网关 50M —— 不把拦截点推到网关(那层返 HTML 413,
  对面更难排查)。rawBody 仍由 create 选项保留,不影响 HMAC 验签。
- all-exceptions.filter.ts: 识别 PayloadTooLargeError(type=entity.too.large,
  辅以 413 兜底)→ 归 10002 + HTTP 200,回执带上限与建议批量,且不上报 Sentry
  (对面发包过大不是 PAC 故障)。口径对齐文档 §9.1「字段校验失败/批量超限 → 修正后重发」。
- channel-push.mdx §10: 补字节上限,并给按表的分批建议(病历 50-100 行 / 结构化 500 行)。

验证(本地起真实服务,真 HMAC 签名):
  146B / 300KB / 2MB / 8MB → 全部通过验签进入摄入流水线(证明 rawBody 未被破坏)
  11MB                     → 10002 + HTTP 200,回执可指导动作
  636 tests passed,service/web typecheck 通过。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>