feat(ai): 每个数据页面都有 AI 解读，靠一条带优先级的生产者/消费者队列

原来只有今日页有晨报、指标详情页有归因，其余页面一片空白。现在除设置外
的 10 个页面都有：健康、睡眠、运动、趋势、每日、身体成分、成绩预测、
身体年龄、挑战赛、运动详情。

不是给每个页面写一套，而是一个通用管线：
- services/scopes.py：一个页面一个 context builder，返回同一个信封。
  context["highlights"] 是已经算好的白话事实——模型负责解读它们，模型不
  可用时规则引擎原样渲染。两者引用同一批数字，所以降级读起来不像换了个 App。
  没数据的页面返回 None，宁可不出卡片，也不让模型对着空表格发挥。
- coach.scope_messages / parse_scope_insight：一套提示词吃所有页面，页面
  的差异全在 context 里，加页面 = 加一个 builder。
- 前端 <AiPanel scope="…">：一个组件渲染所有页面，轮询逻辑抽成
  lib/insight.ts 的 usePolledInsight，晨报卡也改用它。

## 队列

一次生成 40 秒到 4.5 分钟，所以什么都不能在请求里生成。页面只负责入队，
worker 负责消费（services/jobs.py）。

优先级才是用队列而不是后台线程的理由：同步完成后 prefetch 把所有页面按
背景优先级排进去，可能要跑半小时；而用户一打开某个页面，那个页面的任务
立刻提到队首、下一个就跑。你在看什么，队列就在算什么。

队列放在数据库而不是内存里，因为 gunicorn 有两个 worker：任务带 holder
声明后回读确认，和 scheduler.py 抢 tick 是同一套做法。id 由
user+kind+subject 推导，所以每几秒一次的轮询是幂等的入队，不会每几秒堆一
个任务。

## 网关中断时踩到的两个坑（当场修了）

写完正好赶上 oracle 那台机器不通，于是看到：
- 三次失败后任务被永久标 failed，网关恢复了也不会重试——一次瞬时中断就把
  那个页面的解读判了死刑，直到它的数据碰巧变化。加了冷却期，过期后重置
  尝试次数再排一次。
- 队列已经放弃了，页面还在 pending 转圈，要转满 8 分钟才停。meta.pending
  现在跟着队列状态走，并把失败原因带给卡片。

顺带把 BAND_SOURCES 从 routes/settings.py 下沉到 services/insights.py：
教练要拿它做参照，而 services 不该反向依赖 routes。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

backend/services/insights.py

@@ -69,6 +69,15 @@ def _flatten(day):
     return flat
 
 
+def flatten_days(rows):
+    """`get_summary` output as flat metric maps, with derived shares filled in.
+
+    Public counterpart of `_flatten` for the scope builders, which all need the
+    same normalisation before they can compute anything.
+    """
+    return [_flatten(r) for r in rows]
+
+
 # Metrics the briefing reasons about. `higher_better` drives the plain-language
 # verdict; None means the direction is not meaningful on its own (steps on a
 # rest day are not a failure).
@@ -459,3 +468,34 @@ def window_context(user_id, metric, start, end, rows=None):
             for a in health.get_activities(user_id, start, end)[:40]
         ],
     }
+
+
+# Reference bands, kept beside the UI's RANGES table (client/src/lib/ranges.ts).
+# Each entry says where that metric's band edges came from — the honest answer
+# for several of them is "general-population orientation figures", and it says
+# so. Lives here rather than in routes/: the 评分依据 screen serves it, but the
+# coach also reasons against it, and services must not import from routes.
+BAND_SOURCES = [
+    {"metric": "步数", "bands": "<5k 偏低 · 5–8k 一般 · 8–12k 达标 · >12k 优秀",
+     "source": "步数与死亡率的队列研究（约 8000 步起获益明显，12000 步后趋平）"},
+    {"metric": "静息心率", "bands": "<50 很低 · 50–65 正常 · 65–75 偏高 · >75 较高",
+     "source": "健康成人静息心率 60–100 bpm 为正常范围，规律运动者常低于 60"},
+    {"metric": "心率变异性", "bands": "<25 偏低 · 25–40 一般 · 40–70 良好 · >70 很好",
+     "source": "夜间 RMSSD 的一般人群分布；个体差异极大，趋势比绝对值更有意义"},
+    {"metric": "睡眠时长", "bands": "<6h 不足 · 6–7h 偏少 · 7–9h 充足 · >9h 偏多",
+     "source": "美国睡眠医学会 / 睡眠研究会成人 7–9 小时建议"},
+    {"metric": "压力", "bands": "0–25 休息 · 26–50 偏低 · 51–75 中等 · >75 偏高",
+     "source": "Garmin 官方压力分级，与手表显示一致"},
+    {"metric": "身体电量", "bands": "0–25 很低 · 26–50 偏低 · 51–75 良好 · >75 充足",
+     "source": "Garmin 官方 Body Battery 分级"},
+    {"metric": "血氧", "bands": "<90 偏低 · 90–94 略低 · ≥95 正常",
+     "source": "静息血氧饱和度常用临床参考；腕表光学测量误差较大，仅供趋势参考"},
+    {"metric": "呼吸频率", "bands": "<12 偏低 · 12–20 正常 · >20 偏高",
+     "source": "成人静息呼吸频率 12–20 次/分"},
+    {"metric": "强度分钟", "bands": "<10 偏少 · 10–21 一般 · ≥21 达标",
+     "source": "WHO 每周 150 分钟中等强度活动，折合每天约 21 分钟"},
+    {"metric": "训练准备度", "bands": "0–25 很低 · 26–50 偏低 · 51–75 就绪 · >75 很好",
+     "source": "Garmin 官方 Training Readiness 分级"},
+    {"metric": "爬楼", "bands": "<5 偏少 · 5–10 达标 · >10 优秀",
+     "source": "一般性活动量参考，无权威标准"},
+]