[AI] feat: dramacmt 加补齐与重算两个模式

--top-up：--min~--max 当成目标总条数按差额补，已经落在区间内的不动。
拿每次新摇的目标值比对会让重复跑把条数一路往上限顶，所以按 min 判定。

--recount：把 countComment 重算成 App 列表口径的实际可见条数，铺完自动跑一次。
这个字段只会飘不会自己回来，两个来源：发评论时无条件 +1 而审核不通过和删除都
不回减（后端唯一的重算函数明确跳过 drama）；contentsync 用 $setOnInsert 赋初值
时 countComment 在清单里，源库新剧带着源站的评论数进来而本地一条评论都没有。

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

scripts/dramacmt/README.md

@@ -98,12 +98,49 @@ go build -o /tmp/dramacmt ./scripts/dramacmt/
 /tmp/dramacmt --dst "$DST_HUANGGUO" --db huangguo --users 3000 \
   --min 50 --max 200 --only-empty=false
 
+# 补齐模式：把每部剧补到 50~200 条总量（tangguo 2026-10-30 实际用的参数）
+/tmp/dramacmt --dst "$DST_TANGGUO" --db tangguo --users 5000 \
+  --min 50 --max 200 --only-empty=false --top-up
+
+# 只重算 countComment，不铺评论（每次 contentsync 带进新剧之后都要跑）
+/tmp/dramacmt --dst "$DST_TANGGUO" --db tangguo --recount
+
 # 调试：只跑 3 部，固定种子便于复现
 /tmp/dramacmt --dst "$DST_TANGGUO" --db tangguo --limit 3 --seed 42
 ```
 
 `--db` 必须显式传：URI 里的 `authSource` 通常是 `admin`，推不出业务库名。
 
+### `--top-up`
+
+默认模式下 `--min~--max` 是**新增**条数，`--top-up` 把它当成**目标总条数**，
+按差额补，已经够的跳过。
+
+区别在于底子不空的站：tangguo 的短剧先前已经铺过 20~50 条，照新增算会冲到
+250 条，和其余四站的 50~200 对不上。代价是每部剧多一次 `CountDocuments`
+往返（773 部约两分钟，远端副本集的网络延迟占大头）。
+
+现有条数按 App 列表第 1 页的口径数，不读 `countComment`——那个字段可能是飘的。
+
+### `--recount`
+
+把每部短剧的 `countComment` 重算成 App 列表口径的实际可见条数。铺完会自动跑一次，
+`--no-recount` 可以跳过，`--recount` 则是只重算不铺。
+
+**这个字段只会飘，不会自己回来**，有两个来源：
+
+1. 发评论时 `incCommentCount` 无条件 `+1`（`app/service/commentser/cmtsend.go:224`），
+   审核不通过和删除都不回减。后端唯一的重算函数
+   `web/service/commentser.rebuildSingleObjCommentCount` **明确跳过 drama**
+   （`commentAgent.go:268` 只认 video 和 cartoon），所以线上没有任何一条路会修它
+2. `contentsync` 用 `$setOnInsert` 给新文档的本地字段赋初值，`countComment` 在
+   那份清单里（`scripts/contentsync/spec.go`），于是**源库新剧带着源站的评论数
+   进来，本地却一条评论都没有**
+
+第 2 条意味着每次 contentsync 带进新短剧之后都要重算一次，否则新剧在 App 里显示
+「N 条评论」但列表是空的。2026-11-03 实测：一次增量同步带进 16 部新短剧，
+全都带着源站的 `countComment`。
+
 ## 撤回
 
 机器人用户和评论都带标记，撤回是两条命令：