fix(bangumi-data): 修复 Bangumi Data 开启可能不触发立即下载，并调整云部署数据丢失时下载时机

[wan0ge]

Summary

对 Bangumi Data 的下载触发时机做结构性修正，并调整边缘运行时生命周期延长机制（不再将 ctx 深穿调用栈，改为在边缘层暴露并延长在途下载），覆盖五个维度：

1. 下沉按需下载至消费路径：移除 worker.js 网关层对每次 /search /match /danmaku 请求的统一前置下载，改为在 searchBangumiData 消费路径顶部按需触发（ensureBangumiDataReady），仅真正读取缓存的路径（4 源搜索/匹配/弹幕 + TITLE_TO_CHINESE 中文名 + 跨季 TMDB 边界）才触发；未配置消费源的部署（如仅 renren）整次请求不触碰 Bangumi Data、零下载。
2. 配置变更同步下载生命周期：新增 syncBangumiDataLifecycleOnConfigChange，USE_BANGUMI_DATA 由关到开立即下载、由开到关释放缓存；接入 env-api 三处 handler（前端保存）与 server.js 的 .env 监听器（本地改文件），覆盖云/本地两种启用路径。
3. 修复 getTMDBChineseTitle 漏写 await：tmdb-util.js 调用 searchBangumiData 漏写 await，本地中文名命中路径恒不生效，补 await 后真实生效。
4. 调整边缘运行时生命周期延长机制：不再将 ctx 深穿至数据层，改为暴露在途后台下载 Promise（currentBackgroundDownload），并由 worker.js 的 Cloudflare Workers fetch 入口在响应返回后调用 extendBangumiDownloadLifecycle(ctx) 延长 isolate 生命周期，避免 Serverless 冻结中断在途刷新；无 ctx 的 Node/Vercel/Netlify 自然 no-op。
5. 移除 ctx 参数与 let 声明整理：下载触发下沉后 ctx 不再深穿数据层，移除 handleRequest / initBangumiData 的 ctx 参数（生命周期延长改在边缘层处理）；模块级 let 声明整理为末尾注释并合并组内空行（保留分组分隔），无功能变化。

---

改动明细

1. 移除网关层统一前置下载，下沉按需下载至消费路径

上游原版行为：worker.js 的 Cloudflare Workers fetch 入口在每次请求（含 /search /match /danmaku）进入 handleRequest 时，依据 path 是否含这些路径计算 isDataDependentRequest，并在 globals.useBangumiData 为真时无条件 await initBangumiData(deployPlatform, isDataDependentRequest, ctx)。即任一数据相关请求都会触发下载判断，且 ctx 一路透传到 initBangumiData 用于 waitUntil。

改动后行为：移除 handleRequest 内的全局前置下载；initBangumiData 的 ctx 参数一并移除。新增 ensureBangumiDataReady(deployPlatform)：if (!globals.useBangumiData) return; await initBangumiData(deployPlatform, true);，仅置于 searchBangumiData 顶部。只有真正读取 Bangumi Data 缓存的路径（4 源搜索/匹配/弹幕 + getTMDBChineseTitle + getTmdbSeasonBoundaries）才进入下载判定；未配置任何消费源的部署（如仅 renren）整次请求不碰 Bangumi Data、零下载。

实际观察：

仅 renren 部署的搜索请求不再触发 Bangumi Data 下载；含消费源的请求首次/冷启动仍正常拉起数据，热路径走内存命中秒回。

2. 配置变更同步下载生命周期（syncBangumiDataLifecycleOnConfigChange）

上游原版行为：server.js 的 .env 监听器仅在检测到 USE_BANGUMI_DATA 为 false 时调用 clearBangumiDataCache(true) 释放缓存；无「由关到开」的下载触发。前端 env-api 保存环境变量时完全不触碰 Bangumi Data 生命周期。

改动后行为：新增 syncBangumiDataLifecycleOnConfigChange(deployPlatform)：开关开启时 initBangumiData(deployPlatform, true).catch(console.error)（已缓存则幂等、离线 catch 不影响），关闭时 clearBangumiDataCache(true)。接入 env-api 三处 handler（handleSetEnv/handleAddEnv/handleDelEnv，均在 result 成功且 key === 'USE_BANGUMI_DATA' 时调用）与 server.js 监听器（先 globals.useBangumiData = bangumiEnabled 同步内存开关，再调 sync，避免重载未刷新 globals 时状态滞后）。

实际观察：

前端保存或本地改文件使开关由关到开时立即触发一次下载；由开到关时立即释放缓存。注释态测试覆盖开关切换不抛错且行为安全。

3. 修复 getTMDBChineseTitle 漏写 await

上游原版行为：tmdb-util.js getTMDBChineseTitle 中 const localMatches = searchBangumiData(...) 漏写 await，searchBangumiData 为 async，localMatches 实际为未 resolve 的 Promise，后续 localMatches && localMatches.length > 0 恒为真（Promise 为 truthy）但 localMatches[0] 为 undefined，命中路径从未真正生效。

改动后行为：补 await，localMatches 为真实数组，命中逻辑生效。

实际观察：

注释态测试注入本地缓存条目后，getTMDBChineseTitle('FrobeniusTestAnime') 经 await 返回本地中文名「弗罗贝尼乌斯测试动画」，修复前恒不命中。

4. 暴露在途下载并由边缘运行时延长生命周期（ctx.waitUntil）

上游原版行为：worker.js 的 Cloudflare Workers fetch 入口将 ctx 透传至 handleRequest → initBangumiData，由数据层在下载发起处调用 ctx.waitUntil(downloadPromise) 延长后台下载的生命周期。

改动后行为：initBangumiData 发起非阻塞刷新时经 startDownload 将 Promise 写入模块级 currentBackgroundDownload，下载完成在 .finally 复位；新增 getBackgroundDownload 暴露该状态、extendBangumiDownloadLifecycle(ctx) 仅在存在在途且运行时提供 waitUntil 时注册。worker.js 的 Cloudflare Workers fetch 入口接收 ctx 参数，await handleRequest 后调用 extendBangumiDownloadLifecycle(ctx)；Vercel/Netlify 入口无 ctx，不受影响。

实际观察：

注释态测试验证空闲/缺失 ctx 不注册、在途暴露、响应后由边缘 waitUntil 注册、完成后清理为 null；沙箱真实下载下断言全过。

5. 清理死参数与 let 声明整理

上游原版行为：handleRequest(req, env, deployPlatform, clientIp, ctx) 与 initBangumiData(deployPlatform, isDataDependentRequest, ctx) 携带 ctx 参数，用于数据层直接调用 ctx.waitUntil 延长后台下载生命周期。

改动后行为：移除两处 ctx 参数及 initBangumiData 内依赖 ctx 的 waitUntil 分支（下载生命周期延长改由 extendBangumiDownloadLifecycle 在边缘层处理）。模块级 let 声明整理为末尾注释并合并组内空行（保留分组分隔），无功能变化。

实际观察：

grep 全仓确认无第三参调用方、无残留引用；node --check 通过。

---

实际案例

下沉按需下载前：云部署内存丢失导致每次访问前端都触发下载

某 Cloudflare Workers 部署启用了 USE_BANGUMI_DATA=true，但仅挂载 renren 源（未配置任何消费源）。上游原版在网关层对每次 /search /match /danmaku 请求无条件 await initBangumiData(deployPlatform, isDataDependentRequest, ctx)：

• Serverless 纯内存运行（无 .cache 磁盘挂载），isolate 被平台冻结后 memoryCache 丢失；
• 冻结后的冷请求进入网关前置逻辑时 memoryCache 为空且 isDataDependentRequest=true，触发一次完整网络下载并阻塞等待；
• 该前置逻辑对请求是否真正需要 Bangumi Data 无感知——仅用 renren 的搜索同样会被强制触发下载。

后果：用户每次访问前端、且落在冷 isolate 上时，都要等待一次完整下载才返回，延迟明显；同时对被冻结后反复重建的 isolate，上游 CDN 也承受不必要的请求压力。本分支将下载触发下沉至消费路径后，仅真正读取缓存的路径触发下载，未配置消费源的部署（仅 renren）零下载，热路径内存命中秒回，过期仅后台刷新不阻塞，从根本上消除该问题。

---

影响范围

场景	行为变化
仅 renren 部署（无消费源）	整次请求不触碰 Bangumi Data，零下载（原版即便无关也触发判定）
含消费源的热路径请求	内存命中秒回，与原版一致
含消费源的冷启动/过期刷新	仍触发下载；边缘运行时在途刷新经 waitUntil 延长（机制由数据层深穿改为边缘层暴露）
前端/本地由关到开 USE_BANGUMI_DATA	立即触发下载（原版不触发，需等下次请求）
由开到关	立即释放缓存（原版仅关时释放，现一致且补开启路径）
非 Cloudflare 运行时（Node/Vercel/Netlify/Docker）	无 ctx，extendBangumiDownloadLifecycle 自然 no-op，无回归
getTMDBChineseTitle（TITLE_TO_CHINESE 开启）	本地中文名命中路径真实生效（修复前恒不命中）

---

涉及文件

文件	改动
danmu_api/utils/bangumi-data-util.js	新增 ensureBangumiDataReady / syncBangumiDataLifecycleOnConfigChange / getBackgroundDownload / extendBangumiDownloadLifecycle / startDownload；initBangumiData 移除 ctx 参数、三处刷新分支复用 startDownload；searchBangumiData 顶部 await ensureBangumiDataReady；let 声明整理
danmu_api/apis/env-api.js	handleSetEnv/handleAddEnv/handleDelEnv 在保存成功后对 USE_BANGUMI_DATA 调 syncBangumiDataLifecycleOnConfigChange
danmu_api/server.js	.env 监听器改为先同步 globals.useBangumiData 再调 syncBangumiDataLifecycleOnConfigChange('node')；import 调整
danmu_api/utils/tmdb-util.js	getTMDBChineseTitle 补 await searchBangumiData
danmu_api/worker.js	移除 handleRequest 内全局前置下载及其 ctx 参数；Cloudflare Workers fetch 接收 ctx 并在响应后调 extendBangumiDownloadLifecycle（边缘层延长在途下载，不再深穿数据层）
danmu_api/worker.test.js	注释态新增 bangumi 数据下载时机/配置变更/await 修复 与 在途下载暴露/边缘生命周期 两组测试

[vercel]

@wan0ge is attempting to deploy a commit to the huangxd's projects Team on Vercel.

A member of the Team first needs to authorize it.