perf(logs): label 缓存 TTL 30s + 平台变更即时失效（回答"新 app 会不会延迟"）

问题：加了 60 秒缓存后，新增 app / 新副本 / 新主机采集器要等最久 60 秒
才出现在下拉里，抢修时"刚上线的服务查不到"是不可接受的。

两层处理：

1) TTL 60s → 30s（前后端一致）
   纯 Loki 侧的变更（新 Pod 开始打日志、新副本、主机上新进程写日志）
   最长 30 秒可见。这类变化平台无从感知，只能靠 TTL 兜住。

2) 平台侧变更**立即失效**（不等 TTL）
   新增 InvalidateLabelCache()，在下列入口 defer 调用：
     CollectorService.Create / Update        （主机模式 app 标签来源）
     DeploymentService.Delete                （连带清理托管数据源）
     CreateLogSource / UpdateLogSource / DeleteLogSource
   也就是"用户在平台上做了什么导致候选值集合变化"，缓存当场清掉，
   下一个请求必然回源。这正好覆盖"主机采集的 app 标签"这个场景 ——
   采集器一改，下拉里马上就有。

关于「要不要用定时任务预热」：
   不做。预热只能省掉一次 25~40ms 的网络往返，却要多一个常驻任务和
   一份额外的失败路径；而"时效性"问题已经由上面的即时失效解决了。
   如果将来真要削掉这 40ms，更划算的做法是把 label 值随部署一起下发缓存，
   而不是定时轮询 Loki。

frontend/src/api/logs/index.ts

@@ -34,12 +34,18 @@ export interface DailyVolumePoint {
  *
  * 为什么前端也要缓存：快捷 LogQL 的下拉在「切数据源 / 切命名空间 / 重开面板」
  * 时都会重新走一遍请求链，后端虽然只要 25~40ms，但串起来仍是三四次往返，
- * 用户看到的就是转圈。缓存后同一组合在 60 秒内直接命中内存，体感是"打开就有"。
+ * 用户看到的就是转圈。缓存后同一组合在 30 秒内直接命中内存，体感是"打开就有"。
+ *
+ * 时效性说明：新增 app / 新副本最长 30 秒后出现在下拉里。平台侧的变更
+ * （采集器增删改、部署删除、数据源增删改）会由后端立即清缓存，
+ * 所以"刚配好的 app 找不到"这类问题不会被缓存放大。
  *
  * 用 Promise 作为缓存值：并发的相同请求共享同一个飞行中的请求（去重），
  * 失败时立刻从缓存剔除，避免把错误结果缓存住。
  */
-const LABEL_CACHE_TTL = 60_000
+// 与后端 TTL 对齐（30 秒）：新上线的 app 要在半分钟内可被选中，
+// 同时又能挡住"切命名空间/重开面板"造成的重复请求。
+const LABEL_CACHE_TTL = 30_000
 const labelValueCache = new Map<string, { expires: number; data: Promise<unknown> }>()
 
 function cachedRequest<T>(key: string, run: () => Promise<T>): Promise<T> {