refactor(analysis): 去掉排行 10/30/50 选择器，改为一次取 50 + 前端分页；零点结算昨天

=== 1. 为什么去掉「显示条数」选择器 ===
topk 的 N 不影响查询成本（扫描的 chunk 集合完全相同），实测：
  topk(10)  17833ms / 11 条
  topk(30)  18019ms / 34 条
  topk(50)   7394ms / 54 条
  topk(100) 17553ms / 74 条
波动来自集群负载，与 N 无关 —— 它只决定最后返回多少序列。
所以"选 30"既不更快也不更慢，本质是个翻页开关；
而选它还要重新等一次十几秒的查询，纯亏。
改为：一次 topk(50)，前端 10 条/页 → 5 页只需 1 次查询。
附带收益：占比的分母从"前 10 合计"变成"前 50 合计"，更接近真实占比。
副标题明确写清"一次取前 50 个应用（占比按这 50 个合计计算）"。

=== 2. 零点结算昨天（daily volume）===
原来只有 30 分钟 ticker 回补，且启动时间不对齐整点 →
昨天最早的一段可能已经超出 Loki 24h 保留期被删，
结算结果系统性偏低，图上却标"完整一天"，属静默错数。
新增 nextMidnightFinalize()：每天 00:01 触发 FinalizeYesterdayVolume()
  - 昨天定稿 partial=false
  - 补一次条数（index/stats，一天一次可接受）
  - 顺带刷新今天 partial=true 的柱子
ticker 仍保留，负责当天数据的 30 分钟刷新。

=== 3. 顺带 ===
- 去掉每日量"其中 N 天平台没有留存记录"的提示文案（按用户要求）
- 修 QuickQueryTemplates.tsx 的未使用变量导致 tsc -b 失败
- 工作区里上一轮中断的"排行体积列"改动一并纳入（app-ranking 返回 bytes，
  TopAppsTable 增加体积列，快照记录 per-app 字节数）

Pod = Hub latest = a16978d2f88b

docs/user-guide/analysis.md

@@ -4,12 +4,43 @@
 
 ![日志分析](/docs/assets/screenshots/analysis.png)
 
-- **统计卡**:日志总量、错误行数、告警行数、活跃应用
-- **趋势折线**:总量 / 错误 / 告警随时间分布
-- **命名空间分布**:环形图
-- **应用流图**:Top 10 应用日志量堆叠
-- **每日日志量**:近 7 天按日聚合(独立于时间范围筛选)
-- **应用排行**:Top 10 应用,支持跳转查询页
+- **统计卡**:日志总量、日志体积、错误行数、活跃应用
+- **趋势折线**:按时间分桶的日志体积(≤12 小时 15 分钟一桶,>12 小时 1 小时一桶)
+- **应用排行**:按**日志体积**排 Top 10,支持 10/30/50 与前端分页,点击「查看日志」跳转查询页
+- **每日日志量**:平台留存历史,支持 7 / 30 / 90 / 365 天切换(独立于上方时间范围)
 - **Ingress 访问分析**:自动识别 ingress-nginx 访问日志,PV/UV、状态码、慢请求与接口排行;未安装 ingress-nginx 时自动折叠
 
+## 数据来源与耗时
+
+| 数据 | 来源 | 耗时 |
+|------|------|------|
+| 总量/体积趋势、总条数 | Loki 索引接口(`index/volume_range`、`index/stats`),只读 chunk 元数据 | 百毫秒级 |
+| ≤1 小时范围的应用排行 | 实时扫描日志内容(`count_over_time`) | 5 分钟窗口约 5~10 秒 |
+| >1 小时范围的应用排行 | 平台**按小时预聚合快照**(每小时第 5 分钟抓上一个完整小时) | 毫秒级 |
+
+> 一次分析页要跑多条按应用的重查询,因此筛选栏改条件后**点「刷新」才生效**;
+> 应用排行卡片滚动到可视区才发起重查询,避免首屏一起等。
+
+## 应用排行的「体积」口径
+
+预聚合快照对每个应用每小时同时留存 **条数 + 体积**:
+
+- 条数走 `count_over_time`(要解码日志内容,一小时代价高,每小时后台跑一次)
+- 体积走 `index/volume`(Loki 索引接口,一个应用约 80ms,所以长范围排行也能按体积排序)
+
+体积优先排序的原因:条数会被高频短日志主导(一条 INFO 刷屏 vs 一条大 JSON),
+用户真正关心的是「哪个应用把日志量吃掉了」。
+
+体积列上线前抓的小时只有条数,页面会在表格下方提示
+「其中 N/M 小时有体积数据…」——**不要把这个提示当成故障**,
+它是在说明这段时间的体积偏小是采样口径问题,而不是应用体积真的小。
+
+## 每日日志量的「未留存」
+
+每日量来自平台自己的留存库(默认保留 400 天),不受 Loki retention(72 小时)限制。
+
+- **今天的柱子**是「进行中」,每 30 分钟刷新一次;零点后 1 分钟结算前一天
+- **灰色柱 = 平台没有留存记录**(平台当天没运行 / 超出留存期),**不是「当天没有日志」**
+- 如果缺失的天画成 0,30/90 天视角会出现大片空柱,容易被误读成「以前日志量很低」甚至「系统停摆过」
+
 时间范围与数据源在页面顶部切换;指标查询经服务端聚合,开销远低于拉取原始日志。

docs/user-guide/query.md

@@ -7,7 +7,7 @@
 ## 查询方式
 
 - **LogQL 编辑器**:语法高亮与标签/管道补全;回车执行。
-- **快捷查询**:选择命名空间缩小范围后,选中 App / Pod 即自动填入并执行;Ingress 访问日志按钮在选择 ingress 命名空间或 app 时出现。
+- **快捷查询**:先选命名空间,再选 App / Pod(候选值**按级联懒加载**:选了命名空间才会去取 App 列表,选了 App 才取 Pod 列表,避免一进页面就把 Loki 索引扫一遍),选中即自动填入并执行;Ingress 访问日志按钮在选择 ingress 命名空间或 app 时出现。
 - **Label 浏览器**:按标签与值点选构建查询;点结果行的标签值可快速加过滤。
 - **Live Tail**:3 秒轮询最近 5 分钟,编辑查询自动防抖后切换。