现象:企微收不到每日健康日报。09-01 / 09-02 两天都在 **09:00:10** 失败
(= cron 09:00:00 + 10s pool_timeout),报错是拿不到连接而不是推送失败:

  Invalid `prisma.followupPlan.count()` invocation:
  Timed out fetching a new connection from the connection pool
  (Current connection pool timeout: 10, connection limit: 5)

根因两条叠加:

① **常驻服务的并发旋钮没被算进池。** withCohortDerivedPool 只认 PAC_DB_CONCURRENCY /
   PAC_COHORT_CONCURRENCY(都是 CLI 的旋钮),而 PAC_RECALL_SUBSCENARIO_CONCURRENCY=4
   (2026-08-30 在生产开启,场景段 ×2.31)是**常驻进程**的旋钮 —— 批次因此长期占住 4 条连接,
   池却还是 Prisma 默认。函数开头那句「一调并发就得手动调池,这里把两者联动」说的就是这个病,
   只是当时只联动了 CLI 那半边。

② **生产的默认池只有 5,不是注释里写的 9。** Prisma 默认池按**物理核**×2+1 算:
   生产机 nproc=4 但 `Core(s) per socket`=2 / `Thread(s) per core`=2 → 物理核 2 → 池 = 5。
   原注释按逻辑核算成 9,低估了一倍,实现和测试文件里都跟着错。

5 条连接里批次占 4 条,日报要并发发 6 个 count → 排队 → 10 秒超时。
同一根因还打掉过一条 plan upsert(`Unable to start a transaction in the given time`,
09-01 21:47,549,106 个命中患者里 1 个)。

改动:把 PAC_RECALL_SUBSCENARIO_CONCURRENCY 并入取最大 → 生产池 4×6+5 = 29。
生产 RDS max_connections=820(实测,当时全库仅 23 条在用),29 条毫无压力。

⚠️ 09:00 撞在 08:15 那轮的召回场景段(08:44~09:35)中间是**天天必撞**,不是偶发;
   这里选择扩池而不是挪 cron —— 挪 cron 只躲开这一个碰撞,扩池同时修掉 API/plan 侧的抢连接。

顺带把三处写错或缺失的口径补上:实现注释、.env.example(DATABASE_URL 与并发旋钮的耦合、
显式 connection_limit 会让自动放大整个失效)、以及 conc 读取处的反向指引。

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