2026-08-28 那次修的是 dryRun 分支(整份 patientIds 塞进 `IN` → 3.2 万清单直接炸
`too many bind variables ... expected maximum of 32767, received 62899`)。
但只修了一半:**实跑分支的旋钮没有上限**

  const BATCH = Math.max(1, Number(process.env.PAC_REPARSE_BATCH) || 3000);
                ↑ 只夹下限

`PAC_REPARSE_BATCH=50000`(有人想"跑快点")就会让同一堵墙从实跑那侧长回来 ——
每个 patientId 占一个 bind,墙在 32,767。

改动:抽出 `reparseBatchSize()`,夹在 `PG_MAX_BIND_VARS - 100`(留 where 里
hostId/subjectType 等其余 bind 的余量),**dryRun 与实跑共用同一个值** ——
两侧各写一份是这个 bug 反复长回来的原因。

测试(tests/reparse-dry-run-bind-limit.spec.ts,3 条):
  · 假 prisma **照 PG 的规矩发脾气**:单条 count 的 bind 超限就抛同样的错。
    不这么做的话"不分批"也能测过,是假绿。
  · 62,899 患者(事故量级)dry-run 不抛;分片不重不漏(累加 = 62,899);
    并断言 count 真发出去过(>1 次)—— 防"被判为非 transform 产出静默跳过"的假绿。
  · 不给清单时走全量 count(where 里没有 IN,不占 bind)。
  · ⛔ PAC_REPARSE_BATCH=100000 也不许把墙放回来 ← 本次新增的那半。

有牙验证:把夹子退回 `Math.max(1, raw)`,第 3 条立刻以生产原话失败
(`received 50002`),不是写完就绿的摆设。

出处:这份改动originally 躺在 worktree claude/peaceful-nightingale-940534 里未提交
(fixtures + spec 都建好了但没落),清理分支时捞出来落到 main 当前的代码形态上。

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