fix(fulfillment): 履约回填改用 keyset 分页并补充待回填部分索引

- 迁移 108：order_items (id) WHERE fulfillment_mode IS NULL 部分索引
  生产已 CONCURRENTLY 预建；取 5000 条待回填 id 4.8s → 4.9ms
- reconcilePendingFulfillmentModes 增加 afterId / lastScannedId，批内固定 id > 游标
- 新增 resolveReconcileCursor：游标单调前进，未前进或不足一批即结束
- backfill-fulfillment-mode 支持 --afterId 断点续跑

apps/backend/src/db/migrations/108_order_items_fulfillment_pending_index.sql

@@ -0,0 +1,27 @@
+-- 108_order_items_fulfillment_pending_index.sql
+--
+-- 背景（2026-10-29 生产实测）：
+-- 「回填履约方式」(fulfillment:backfill) 与每 15 分钟的 cost-finance-sync 都会执行：
+--   SELECT id FROM order_items WHERE fulfillment_mode IS NULL ORDER BY id LIMIT N
+-- 规划器选择 Index Scan using order_items_pkey + Filter，取 1000 条要先翻掉
+-- 335,000 行堆数据（79k blocks），单批 4.8–12.7 秒；5000 条一批接近 60s 上限，
+-- 连续跑会把数据库 IO 打满，在线接口（免审验收）因此撞 15s statement_timeout。
+--
+-- 现有索引都帮不上这个查询：
+--   · idx_order_items_fulfillment_id (fulfillment_mode, id) 规划器不选它
+--   · idx_order_items_fulfillment_pending (order_id) WHERE fulfillment_mode IS NULL
+--     列是 order_id，无法支持 ORDER BY id
+--
+-- 这个部分索引只包含「未判定履约方式」的订单项（当前约 10.5 万行，回填完成后
+-- 只剩新单产生的少量行），让上述查询走 index-only scan 并按 id 顺序取数。
+--
+-- 迁移在 singleTransaction 里执行（见 migrate.ts），这里用普通 CREATE INDEX；
+-- 生产按 086/107 的惯例先执行 CREATE INDEX CONCURRENTLY 预建，
+-- IF NOT EXISTS 会在部署时直接跳过，不锁表。
+
+CREATE INDEX IF NOT EXISTS idx_order_items_fulfillment_pending_id
+  ON order_items (id)
+  WHERE fulfillment_mode IS NULL;
+
+COMMENT ON INDEX idx_order_items_fulfillment_pending_id IS
+  '履约方式回填/定时对账：未判定订单项的部分索引（2026-10-29 性能修复）';