fix(成就): 后台补发成就后重算已解锁数并接着判「奖杯收藏家」；recount 订正存量

rescanAchievement 只插 user_achievement、加 unlock_count，不重算
achievement_unlocked_count，也不做元成就的第二轮判定（旧 rescan_achievement
原样如此）。判题结算只在「这次有新解锁」时才重算，所以被补发的人计数会一直停在
旧值。2026-09-07 一次补发之后 269 人少算，其中 10 人实际够 15 个却没拿到
「奖杯收藏家」。

- 新增 refreshUnlockedCount：一条 SQL 按 user_achievement 重算，只 jsonb_set
  这一个键、只写值变了的行。rescanAchievement 补发非白金成就后调用它，再补发元成就。
- recount 同时核对已解锁数与元成就漏发，--apply 先改计数再补发，复核同一份口径。

用 09-14 生产备份实跑：recount 订正 269 人、补发 10 条，复核通过、重跑无差异，
其余指标 0 行被动；模拟调低阈值补发 1504 条，「奖杯收藏家」随之 65 → 95，
与预先算出的跨线人数一致。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K1d8B3f4SXJwDvUY625eQd

apps/api/src/main.ts

@@ -13,7 +13,7 @@
  *   oj2-api sql-child    # SQL 判题子进程，由服务自己 spawn，不该手动调
  *   oj2-api migrate      # 执行待办的数据库迁移，部署时由 docker/deploy.sh 调
  *   oj2-api backfill-problemsets  # 把题单进度与奖章订正到与规则一致，默认只读预演
- *   oj2-api recount               # 把题目/用户的计数列重算回与 submission 一致，默认只读预演
+ *   oj2-api recount               # 把题目/用户的计数列、成就的已解锁数重算回与明细一致，默认只读预演
  *   oj2-api fix-achievement-hours # 订正「夜猫子」「早起的鸟儿」的历史误发，默认只读预演
  *
  * 用动态 import 而非顶层 import：这几个模块都有导入即执行的副作用