fix(leaderboard): UA 改回 InvolutionHell-SSR + fallback 保留旧 JSON (re-PR #325) (#326)

* fix(leaderboard): 脚本 UA 换 Chrome 伪装规避 CF Bot Fight

故障复盘
PR #322 合并后 prod build 跑 generate-leaderboard.mjs 拿到 Cloudflare 的
403 + "Just a moment..." 挑战页，脚本走 fallback 写空数组上线，
首页 Top Rank / /rank contributors 全空。

根因
api.involutionhell.com 走 Cloudflare，默认 Bot Fight Mode 对短时间内多次
请求或低信誉 IP 段（Vercel build runner）会临时 challenge。当时虽然 UA 含
"build" 关键词加重了被拦概率，但实测换任意 UA 当下都能 200，所以本质是
CF 信誉评分 + 时间窗叠加。

本 PR
脚本 UA 从 "InvolutionHell-build/1.0 (generate-leaderboard.mjs)" 改为标准
Chrome UA，避免任何 "build/script/bot" 关键词触发 CF UA 启发式判定。
跟 backend OgFetchService 的 UA 伪装策略对齐。

长期建议（不在本 PR 范围）
在 Cloudflare 给 api.involutionhell.com/api/public/* 加规则：
  Action: Skip → "Browser Integrity Check" + "Bot Fight Mode"
让公开 API 永远绕过挑战。需要在 CF dashboard 操作。

修复路径
合并 → CI 触发 prod redeploy → generate-leaderboard 拉到真实 21 条 →
首页 Top Rank / /rank contributors 恢复正常。

* fix(leaderboard): fallback 优先保留旧 JSON，避免一次拉失败抹掉好数据

PR #325 自身的 preview build 仍被 CF 403 拦下（log 显示 "Just a moment..."），
说明 UA 伪装救不了——CF 是基于 Vercel runner 的 IP 段信誉评分，跟 UA 无关。
真正的根治是去 CF 给 /api/public/* 加 "Skip Bot Fight" 规则（用户操作）。

本次至少把"一次失败抹好数据"这个二次伤害堵住：
- 拉到数据      → 正常生成
- 拉不到 + 旧 JSON 有非空数组 → 保留旧版，warn 日志，exit 0
- 拉不到 + 旧 JSON 空/损坏     → 写空数组兜底（首次 build 不挂）
- 拉不到 + 旧 JSON 不存在      → 写空数组兜底

效果：
即便 CF 后续仍偶发拦截，prod 上线的 leaderboard 也只会"维持上一版"
而不是"突然空了"。Top Rank 不会因为一次 build 抖动整块消失。

* fix(leaderboard): UA 改回 InvolutionHell-SSR 让 CF Custom Rule 真正匹配

之前误判
昨天看到 build 拿 403 + "Just a moment..." 时，第一反应是"UA 含 build 关键词
触发 CF UA 启发式"，于是把 UA 改成 Chrome 伪装。错了。

实际 CF 配置
api.involutionhell.com 上有一条 Custom Rule：
  (http.host eq "api.involutionhell.com"
   and http.user_agent contains "InvolutionHell-SSR")
  → Skip: Bot Fight Mode / Browser Integrity Check / Managed Rules

也就是说 CF **明确依赖 UA token "InvolutionHell-SSR"** 来识别"自己人"放行。
Chrome 伪装恰恰把这个 token 拿掉，规则不匹配，Vercel runner 仍然按 IP
信誉被 Bot Fight 拦下回 403。

本 PR
脚本 UA 改成
  "InvolutionHell-SSR/1.0 (build; generate-leaderboard.mjs; +https://involutionhell.com)"
带上 CF 规则要求的 token。本机实测 200 + 21 条数据正常返回。

效果
合并后 prod build → CF 规则匹配 Skip → 拉到真实数据 → site-leaderboard.json
回到 21 条 → 首页 Top Rank / /rank contributors 恢复显示。

---------

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Author: longsizhuo

scripts/generate-leaderboard.mjs

@@ -103,7 +103,15 @@ async function fetchAggregatedFromBackend() {
     const res = await fetch(LEADERBOARD_API_URL, {
       headers: {
         accept: "application/json",
-        "user-agent": "InvolutionHell-build/1.0 (generate-leaderboard.mjs)",
+        // UA 必须包含 "InvolutionHell-SSR" —— 这是 CF Custom Rule 的匹配触发词：
+        //   (http.host eq "api.involutionhell.com" and http.user_agent contains "InvolutionHell-SSR")
+        //   → Skip Bot Fight / Browser Integrity / Managed Rules
+        // 之前用 Chrome 伪装时 UA 不含这个 token，CF 规则不匹配，Vercel build runner
+        // 仍然被 IP 信誉评分判定为 bot 回 403（"Just a moment..." 挑战页）。
+        // 改回带 token 的 UA 让 CF 规则真正放行。
+        "user-agent":
+          "InvolutionHell-SSR/1.0 (build; generate-leaderboard.mjs; " +
+          "+https://involutionhell.com)",
       },
       signal: controller.signal,
     });
@@ -145,12 +153,53 @@ async function main() {
   const aggregated = await fetchAggregatedFromBackend();
 
   if (aggregated === null) {
+    // 拉不到后端时优先保留 generated/site-leaderboard.json 旧版本：
+    // 一次 fetch 失败（CF 临时挑战 / Vercel runner IP 信誉低 / 后端短暂抖动）
+    // 不应该把 commit 进 git 的好数据冲成空数组上线。
+    //
+    // 三种情况：
+    //   1. 文件已存在 + 内容是非空数组 → 保留旧数据 exit 0
+    //   2. 文件已存在但是空数组 / 不是数组 → 维持原状 exit 0（不主动覆盖）
+    //   3. 文件不存在（首次 build / 干净 cache）→ 写空数组兜底 exit 0
+    let preservedExisting = false;
+    try {
+      const existing = await fs.readFile(outputAbs, "utf-8");
+      try {
+        const parsed = JSON.parse(existing);
+        if (Array.isArray(parsed) && parsed.length > 0) {
+          console.warn(
+            `[generate-leaderboard] 后端不可用，但保留 ${OUTPUT} 已有 ${parsed.length} 条数据，不覆盖。 | Backend unreachable; keeping existing leaderboard with ${parsed.length} entries.`,
+          );
+        } else {
+          console.warn(
+            `[generate-leaderboard] 后端不可用，且 ${OUTPUT} 已有内容非有效非空数组，维持原状。`,
+          );
+        }
+        preservedExisting = true;
+      } catch {
+        // 文件存在但 JSON 损坏：当作没有，走下面写空兜底
+        console.warn(
+          `[generate-leaderboard] ${OUTPUT} 已存在但 JSON 解析失败，按"首次 build"兜底覆盖空数组。`,
+        );
+      }
+    } catch (readErr) {
+      // ENOENT 等：文件不存在，走兜底
+      if (readErr && readErr.code !== "ENOENT") {
+        console.warn(
+          "[generate-leaderboard] 读取既有 leaderboard 失败：",
+          readErr instanceof Error ? readErr.message : readErr,
+        );
+      }
+    }
+
+    if (preservedExisting) {
+      process.exit(0);
+    }
+
+    // 文件不存在 / 损坏：写空兜底，避免后续 Next import 抛 ENOENT
     console.error(
-      "[generate-leaderboard] 后端不可用，写入空榜单以放行构建。 | Backend unreachable, writing empty leaderboard to unblock build.",
+      "[generate-leaderboard] 后端不可用且本地无可保留数据，写入空榜单以放行构建。 | Backend unreachable and no existing data, writing empty leaderboard to unblock build.",
     );
-    // mkdir + writeFile 必须放同一个 try：任一步失败都意味着 generated/site-leaderboard.json
-    // 不存在，后续 Next 端 import 会抛更难定位的 ENOENT。这种情况 build 必须 fail-fast，
-    // 不能 exit 0 让"看起来一切正常"的 deploy 把站点搞挂。
     try {
       await ensureParentDir(outputAbs);
       await fs.writeFile(outputAbs, "[]", "utf-8");