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/services/worker-platform/worker-platform-service.test.ts

@@ -2533,3 +2533,59 @@ test('押金已退还或已没收时不再尝试二次冻结（台账唯一索
     '这个码要被服务层识别并映射成 409 文案，不能漏成 500',
   )
 })
+
+test('筛选统计必须优先读派生列 source_order_amount_fen，不再逐行解析 material_json', async () => {
+  const { readFile } = await import('node:fs/promises')
+  const queryRepo = await readFile(
+    new URL('../../repositories/worker-platform/work-order-query-repo.ts', import.meta.url),
+    'utf8',
+  )
+  // 统计表达式：列 → JSON 兜底 → orders.total_amount，COALESCE 从左到右短路
+  assert.ok(
+    queryRepo.includes('wo.source_order_amount_fen'),
+    '统计没有走派生列，又会退化成每次解析全表 JSON（生产实测 2.8 秒）',
+  )
+  const paymentBlock = queryRepo.slice(
+    queryRepo.indexOf('const WORK_ORDER_PAYMENT_AMOUNT_SQL'),
+    queryRepo.indexOf('export async function getWorkOrderStatistics'),
+  )
+  assert.ok(
+    paymentBlock.indexOf('wo.source_order_amount_fen') <
+      paymentBlock.indexOf("material_json->'source'->>'orderAmountFen'"),
+    '派生列必须排在 JSON 兜底之前，否则短路失效、等于没优化',
+  )
+  assert.ok(
+    paymentBlock.includes('COALESCE(o.total_amount, 0)'),
+    '最后一级兜底必须与改造前一致（回退 orders.total_amount）',
+  )
+
+  // 两个写入点都要维护派生列，否则新单全是 NULL（虽然能兜底，但白优化）
+  const managementRepo = await readFile(
+    new URL('../../repositories/worker-platform/work-order-management-repo.ts', import.meta.url),
+    'utf8',
+  )
+  const writes = managementRepo.split('resolveSourceOrderAmountFen(').length - 1
+  assert.equal(writes, 2, '派生列写入点必须正好两处：建单 INSERT 与通用 UPDATE')
+  assert.ok(managementRepo.includes('source_order_amount_fen = $17'))
+})
+
+test('会话 touch 必须同时保留鉴权语义与写入节流', async () => {
+  const { readFile } = await import('node:fs/promises')
+  const src = await readFile(
+    new URL('../../repositories/worker-platform/worker-session-repo.ts', import.meta.url),
+    'utf8',
+  )
+  const body = src.slice(
+    src.indexOf('export async function touchWorkerSession'),
+    src.indexOf('export async function revokeWorkerSession'),
+  )
+  // 返回值是鉴权有效性：上层 !(await touch) 会直接 401，不能因为"不写"就返回 false
+  assert.ok(body.includes('EXISTS (SELECT 1 FROM target) AS valid'), '必须仍然返回会话是否有效')
+  assert.ok(body.includes("status = 'active'"), '有效性判定不能丢')
+  // 写操作必须节流：32 天里被写了 3300 万次
+  assert.ok(body.includes('WORKER_SESSION_TOUCH_MIN_INTERVAL'), '缺少节流间隔常量')
+  assert.ok(
+    body.includes('ws.last_seen_at < ($2::timestamptz - INTERVAL'),
+    '写入必须带 last_seen_at 未刷新判定，否则等于没节流',
+  )
+})