feat(analysis,alerts): 每日量落库看历史趋势、趋势图/饼图可读性、告警三分页

=== 1. 每日日志量必须落库（核心问题：Loki 只留 24 小时）===
实测：请求"近 7 天每日量"，Loki 只返回 27 个**小时**桶，全部在最近 24h 内 ——
因为 retention_period=24h，更早的 chunk 已经被删了。
也就是说「固定近 7 天」这张卡片，过去一直是"6 天空白 + 1 天有数据"，
用户看着像坏了，实际是数据物理不存在。

方案：平台自己留存历史。
  - models.DailyVolumeSnapshot{Date(本地YYYY-MM-DD), SourceID, Bytes, Entries, Partial}
  - services/daily_volume.go
      CaptureDailyVolume        按天抓 index/stats 落库（幂等覆盖）
      StartDailyVolumeCapture   启动 20s 后回补 + 每 30 分钟检查一次
      GetDailyVolumeHistory     读库返回最近 N 天（今天会实时补抓）
  - 保留 400 天（够看年度趋势），按 source+date 去重
  - 前端可选 7 / 30 / 90 / 365 天，能看多长取决于平台积累多久

为什么用"每 30 分钟检查昨天有没有落库"而不是固定 00:10 定时：
平台可能整晚没运行，固定时点的定时器会直接错过；检查式回补不依赖平台在线时刻。

Partial 标记（关键，否则会误读）：
  - 当天未结束 → partial=true
  - 待抓取日期的起点已超出 24h 保留期 → partial=true（Loki 里就没那么多数据）
实测：10-27 32.5GB/2.65亿条 partial=true（保留期外），
      10-28 348GB/28.56亿条 partial=true（当天进行中）

=== 2. 修一个 Go 副本 bug（自己写的，靠实测发现）===
第一版用 `for _, snap := range db.DailyVolumeSnapshots` 后改 snap 字段，
range 拿到的是**副本**，改动不会写回切片 → 同一天永远保持首次抓取的值，
partial 也永不更新（实测发现 10-27 该是 true 却显示 false）。
改为 `for i := range ... { snap := &db.DailyVolumeSnapshots[i] }`。

=== 3. 趋势图可读性 ===
从"裸折线"换成"渐变面积图"，并在图上方给出峰值 / 均值：
  - 面积图能一眼看出"这一段整体比上一段高"，折线只能靠对齐格子数
  - 峰值/均值避免用户自己对刻度
  - Y 轴与 tooltip 统一 formatBytes，"每桶体积"写进 subtitle
顺带确认：趋势图只画体积（字节），不再混入 error（条数）——单位不同不能同轴。

=== 4. 饼图：命名空间分布 → 应用日志量分布 ===
本环境的命名空间只有 astralx / log 两个，饼图没有信息量；
改成按应用看谁在刷日志（前 8 名 + 其他），才是运维真正要的答案。

=== 5. 告警页拆成三个 Tab ===
「告警规则 / 通知通道 / 发送历史」独立成分页（用 ui/tabs）。
之前通道是折叠块、历史堆在规则下面，规则一多就要滚很久才看得到。
发送历史增加空状态文案，不再是"空页面不知道有没有在发"。

=== 6. 内置规则关联默认通道 + 首次部署 webhook 留空的评估 ===
结论：**webhook 可以留空，但通道必须是禁用状态**。
  - 若种子给的是"已启用 + 空地址"通道，规则一命中就必然投递失败，
    发送历史堆满红色失败，反而让人以为平台坏了
  - 所以首次部署建一个**禁用**的占位通道「默认通知通道（待配置 Webhook）」，
    内置规则全部挂到它；管理员填好 Webhook 再启用即可，不用逐条关联
  - 保存时加校验：启用则必须有非空 Webhook（返回明确原因，不是裸 500）
  - schemaVersion v5→v6：把已有的"无通道"规则补挂到默认通道
  实测：8 条规则全部已关联通道

=== 实测（v11-1028-2252 / 187062644c0f）===
  /logs/daily-volume?days=7  → 2 天数据，partial 标记正确
  规则 8 条全部有 channelIds
  平台 ready、健康 ok

backend/seed/alert_rules.go

@@ -31,6 +31,40 @@ type builtinRule struct {
 //  3. cooldown 统一 ≥ 120 分钟：同一问题 2 小时内只提醒一次。
 //  4. 绝对阈值天然不跨环境通用，大集群（如 300GB/天）必须按 app/namespace
 //     收窄查询，否则任何阈值都会被常态流量击穿。这一点在 UI 上有提示。
+//
+// ensurePlaceholderChannel 返回一个可挂靠的通道 ID：
+// 已有通道取第一个；没有则建一个禁用的占位通道。
+func ensurePlaceholderChannel(db *repository.JsonDB) uint {
+	db.Lock()
+	defer db.Unlock()
+	if len(db.NotifyChannels) > 0 {
+		return db.NotifyChannels[0].ID
+	}
+	next := uint(0)
+	for _, ch := range db.NotifyChannels {
+		if ch.ID > next {
+			next = ch.ID
+		}
+	}
+	id := next + 1
+	db.NotifyChannels = append(db.NotifyChannels, models.NotifyChannel{
+		ID:        id,
+		Name:      "默认通知通道（待配置 Webhook）",
+		Enabled:   false,
+		CreatedAt: time.Now(),
+		UpdatedAt: time.Now(),
+	})
+	return id
+}
+
+// channelIDsFor 把单个通道 ID 包成切片；0 表示没有可用通道（保持空）。
+func channelIDsFor(id uint) []uint {
+	if id == 0 {
+		return nil
+	}
+	return []uint{id}
+}
+
 var builtinRules = []builtinRule{
 	// —— 致命类：这类日志本该极少出现，但也不能一条就报 ——
 	{name: "致命日志 FATAL", query: `{namespace=~".+"} |= "FATAL"`, windowMin: 15, threshold: 10, cooldown: 120},
@@ -77,6 +111,14 @@ func SeedAlertRules() {
 	// 绑定第一个 managed 数据源(通常是唯一部署)
 	target := sources[0]
 
+	// 内置规则一律挂到默认通知通道。
+	// 首次部署没有任何通道时，这里建一个**禁用**的占位通道（Webhook 留空）：
+	//   - 规则不会变成"孤儿"（发送历史会明确写"通道未投递"而不是静默）
+	//   - 管理员填好 Webhook 再启用即可，不必逐条给规则关联通道
+	//   - 之所以不放"已启用 + 空地址"：那样每次命中都会投递失败刷屏
+	// 这里直接操作 db 而不调 services，避免 seed ↔ services 的包循环依赖。
+	defaultChannelID := ensurePlaceholderChannel(db)
+
 	newID := db.NextID("alertRules")
 	db.Lock()
 	defer db.Unlock()
@@ -89,7 +131,8 @@ func SeedAlertRules() {
 			ID: newID, Name: r.name, SourceID: target.id,
 			Query: r.query, WindowMin: r.windowMin, Threshold: r.threshold,
 			Enabled: false, CooldownMin: r.cooldown,
-			CreatedAt: time.Now(), UpdatedAt: time.Now(),
+			ChannelIDs: channelIDsFor(defaultChannelID),
+			CreatedAt:  time.Now(), UpdatedAt: time.Now(),
 		})
 	}
 	db.RequestSave()