fix: optimize GitHub Actions workflows — fix slow CI (1h 48m) and broken freeze cache

[Copilot]

问题背景

Github Page workflow 中 "Pre-render all non-frozen QMD files" 步骤耗时 1h 48m，整个 CI 运行超过 2 小时。经根因分析，共发现 5 个相互关联的 workflow 配置问题。

根本原因分析

核心问题：nightly 保存的 freeze 缓存几乎为空

babelquarto::render_website() 在临时目录（withr::local_tempdir()）中渲染，在那里生成 _freeze，然后只把 _site 复制回工作区，临时目录（及其 _freeze）被丢弃。因此 nightly workflow 调用 babelquarto 后，工作区 _freeze 几乎没有任何 R 文件的输出，保存的缓存无效。当 main workflow 恢复了这个无效缓存后，仍需从头重新渲染所有 60+ 个 R QMD 文件，耗时 1h 48m。

修复内容

P0：quarto-publish-update-cache.yml — 添加 Pre-render 步骤（根本修复）

在 nightly 调用 babelquarto 之前，加入与 main workflow 相同的 "Pre-render all non-frozen QMD files" 步骤，将所有 R QMD 的输出写入工作区 _freeze。这样：

• 保存的缓存包含完整的 ~500+ 条 frozen 输出
• babelquarto 从缓存中读取已有输出，只执行 pandoc，耗时从 ~90 min 降至 ~20 min
• warm cache 下整体运行时间从 ~1h 48m 降至 ~20 min

P0：quarto-publish-update-cache.yml — 修复并发组名称冲突

原 nightly 并发组为 quarto-build-Github Page-refs/heads/main，与 main workflow 的并发组完全相同。main workflow 设置了 cancel-in-progress: true，导致每次有 PR 合并到 main，正在运行的 nightly 就会被取消，缓存无法保存。

修复：将 nightly 并发组改为独立名称 quarto-build-nightly-cache-update。

P1：quarto-publish-update-cache.yml — 增加 timeout 到 240 分钟

首次冷启动加入 pre-render 步骤后，总耗时约 140 min（Julia setup + pre-render ~80 min + babelquarto ~20 min + 其他 ~40 min）。原 150 min timeout 已不够。

P1：quarto-publish-update-cache.yml — 统一缓存键前缀，限制缓存增长

• 修复 restore 主键：原主键使用 github.sha（每次 commit 都变化，从不命中），改用 run_id-run_attempt 确保同一 run 的 retry 能直接命中自己的缓存
• 统一前缀：改用 freeze-<OS>-nightly- 前缀，使 main workflow 的 restore-keys: freeze-<OS>- 能稳定匹配
• 限制缓存增长：使用周日期键（YYYY-WNN）每周最多创建 ~7 条缓存条目，旧条目在 7 天未使用后被 GitHub 自动清除

P2：quarto-publish.yml — 排除 .zh.qmd 文件触发

自动翻译 PR 只修改 .zh.qmd 文件，但仍会触发完整 2+ 小时站点构建。在 push 触发的 paths-ignore 中加入 **/*.zh.qmd 可避免此类不必要的构建。

预期效果

场景	修复前	修复后
warm cache 构建（pre-render 步骤）	~1h 48m	~0 min（全部跳过）
babelquarto 步骤	~12 min	~20 min（pandoc only）
整体 CI 时间	~2h 10m	~35 min
nightly 被 push 取消	常见	不会发生
翻译 PR 触发完整构建	是	否

[github-actions]

✅ QMD Format Check

No new QMD tutorial files to check.

Automated check by the PR Review workflow.
See contribution guidance for the expected tutorial format.