perf(db): 统计金额落到列上、会话刷新节流、补齐保留与内存治理

背景：生产 32 天内 >500ms 慢查询从 2.4k/天涨到 1.3 万/天（09-26 尖峰 14.3 万），
pg_stat_statements 显示后台工单列表族占 57%、打手端 visible_orders 占 27%；
同时 backend 容器十天从 194MB 涨到 754MB(768MB 限额的 98%)，贴顶后整体变慢。

1. 新增迁移 083：work_orders 增加派生列 source_order_amount_fen，并从
   material_json.source.orderAmountFen 回填（只认 15 位以内整数，与 JS/SQL 口径一致）。
   统计查询原来每行要解析 1.2KB JSON（全表约 132MB）且同一表达式求值两次，
   生产实测 3.5~4.4 秒；改走派生列后 COALESCE 短路，未命中列的行才回退 JSON/orders.total_amount，
   口径与改造前完全一致。写入点：createWorkOrder / updateWorkOrder 各一处，并加静态守卫。
2. worker_sessions.last_seen_at 从"每个请求都写"改为"5 分钟才写一次"：
   32 天被写了 3300 万次（占 DB 总时间 2.8%，并堆出 14% 死元组）。仍用一条语句返回鉴权有效性
   （EXISTS target AS valid），不能因为不写就让上层 401。
3. 保留策略补上 work_order_events（71.7 万行 / 269MB，此前完全没纳入清理，只增不减），
   新增配置 retention.workOrderEventDays（默认 180 天）与 WORK_ORDER_EVENT_RETENTION_DAYS 出口。
4. 内存治理：compose 后端限额 768m→1g 并显式设置 V8 老生代上限（--max-old-space-size=768），
   避免贴 cgroup 上限后 GC 抖动；新增每 10 分钟的进程内存快照日志（rss/heapUsed/heapLimit），
   用于区分"正常 GC 曲线"与"真泄漏"。
5. 限流桶加 5 万条硬上限：key 里含请求体字段（collect 的 orderNo）时可被构造成高基数，
   只按过期清理挡不住内存增长。

验证：后端 530 项单测全绿（新增 11 项，含派生列/会话/保留的静态守卫与解析函数单测）。

apps/backend/src/middleware/rate-limit.test.ts

@@ -136,3 +136,11 @@ function createMockResponse(): Response & {
     body: any
   }
 }
+
+test('限流桶有数量硬上限：key 含用户可控字段时不能无限膨胀', async () => {
+  const { readFile } = await import('node:fs/promises')
+  const src = await readFile(new URL('./rate-limit.ts', import.meta.url), 'utf8')
+  // collect 路由的限流 key 里带请求体 orderNo（可被构造），只按过期清理挡不住高基数灌键
+  assert.ok(src.includes('MAX_RATE_LIMIT_BUCKETS'), '缺少限流桶数量上限')
+  assert.ok(src.includes('buckets.size > MAX_RATE_LIMIT_BUCKETS'), '必须在清理时按上限淘汰最老的桶')
+})

apps/backend/src/middleware/rate-limit.ts

@@ -25,6 +25,8 @@ type RateLimitBucket = {
 
 const buckets = new Map<string, RateLimitBucket>()
 let lastCleanupAt = 0
+/** 限流桶数量硬上限：key 含请求体字段时可被构造成高基数，必须兜底防止内存无限增长。 */
+const MAX_RATE_LIMIT_BUCKETS = 50_000
 
 export function createRateLimitMiddleware({
   scope,
@@ -120,4 +122,17 @@ function cleanupExpiredBuckets(now: number): void {
       buckets.delete(key)
     }
   }
+
+  // 兜底：限流 key 里含请求体字段（如 collect 路由的 orderNo），是可被构造的高基数键，
+  // 只按"过期"清理挡不住短时间内灌进来的海量新键。这里再加一道硬上限，
+  // 超限时按插入顺序淘汰最老的桶（Map 保持插入序），保证内存不随扫描流量无限涨。
+  if (buckets.size > MAX_RATE_LIMIT_BUCKETS) {
+    const overflow = buckets.size - MAX_RATE_LIMIT_BUCKETS
+    let removed = 0
+    for (const key of buckets.keys()) {
+      buckets.delete(key)
+      removed += 1
+      if (removed >= overflow) break
+    }
+  }
 }