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/db/migrations/083_work_order_source_amount_column.sql

@@ -0,0 +1,27 @@
+-- 083_work_order_source_amount_column.sql —— 把「用户付款金额」从 material_json 落到列上。
+--
+-- 背景：后台接单工单列表的「本次筛选统计」每次刷新都要算
+--   SUM(material_json->'source'->>'orderAmountFen' ...)
+-- 该表达式带正则校验、每行要被求值两次（总付款 + 退款），而 material_json 平均 1.2KB，
+-- work_orders 9.6 万行时单次查询要解析约 132MB JSON，实测平均 2.8 秒（pg_stat_statements）。
+-- 这条查询随工单量线性变慢，是"系统越跑越慢"的主因之一。
+--
+-- 处理：新增 source_order_amount_fen 派生列。
+--   - 有合法值 → 写入该列，统计时直接读列（不再碰 JSON）；
+--   - 没有合法值 → 留 NULL，统计逻辑回退 orders.total_amount（与改造前语义完全一致）。
+-- NULL 表示"来源没给"，不是"金额为 0"，因此不能用 0 当缺省值。
+
+ALTER TABLE work_orders
+  ADD COLUMN IF NOT EXISTS source_order_amount_fen BIGINT;
+
+COMMENT ON COLUMN work_orders.source_order_amount_fen IS
+  '来源订单用户付款金额（分）：取自 material_json.source.orderAmountFen；NULL 表示来源未提供合法值，统计回退 orders.total_amount。由 createWorkOrder / updateWorkOrder 同步维护。';
+
+-- 回填历史数据。只认 15 位以内的整数，三处口径必须一致（本迁移、统计 SQL、
+-- repositories/worker-platform/shared.ts 的 resolveSourceOrderAmountFen）：
+-- 正则放行超长数字时 ::bigint 会直接报 22003，让整条迁移失败回滚；
+-- 15 位以内也保证 JS 侧 Number 能精确表示。
+UPDATE work_orders
+SET source_order_amount_fen = (material_json->'source'->>'orderAmountFen')::bigint
+WHERE source_order_amount_fen IS NULL
+  AND COALESCE(material_json->'source'->>'orderAmountFen', '') ~ '^-?[0-9]{1,15}$';