[muuuuuuushroom]

改动概述

支持按用户收藏夹顺序批量生成视频笔记，并在生成历史中按收藏夹筛选、批量导出所选视频的 Markdown 文档。

为什么

私有收藏夹中的视频需要逐条使用相同配置处理；完成后也需要按收藏夹整理结果并一次性导出，避免逐个查找和下载。

做了什么

• 新增收藏夹批量处理界面及后端收藏夹接口，按顺序串行生成笔记。
• 在历史记录中增加收藏夹筛选，并支持选择多个视频批量导出 Markdown。
• 保留单视频笔记生成流程，并同步更新 README 功能说明。

测试方式

• corepack pnpm@9.15.0 run build 通过。
• python -m unittest tests.test_favorites 通过（6 项）。
• python -m py_compile app/__init__.py app/routers/favorites.py 通过。
• 用户已手动验证收藏夹生成、历史筛选和批量导出流程。
• git diff --check 通过；与 master 对比未发现新增 ESLint 诊断。
• 检查 PR 文件清单，不包含 GPU/CUDA、Whisper、监控或服务启动/关闭脚本改动。

前端 package.json 未定义 typecheck 脚本，因此无法按贡献指南运行 pnpm typecheck；生产构建已通过。

回归风险

改动影响收藏夹批处理接口和历史记录交互；单视频笔记流程保持原有调用路径。批处理按顺序执行，失败项按接口返回状态处理。

部署影响

前后端需一并部署；无需额外配置迁移。

Checklist

• base 分支为 master（上游当前没有 develop 分支；仓库近期 PR 也有合入 master 的先例）。
• Commit message 遵循 type(scope): subject 格式。
• 已完成核心流程自测。
• 本 PR 仅包含收藏夹功能相关改动。
• 未包含 secrets、.env 或大型二进制文件。

后续修复

• Bilibili 收藏夹接口返回的 page 表示一个收藏项包含的分 P 数量；此前只保留了 BV 号，导致多 P 视频始终处理第 1 P。
• 现在将多 P 视频展开为 ?p=1、?p=2 等独立任务，并使用视频 + P 序号作为唯一键，避免状态和选择互相覆盖。
• 针对多 P 视频新增接口测试，验证 3 个分 P 均生成独立链接。
• 多 P 标题通过 Bilibili x/web-interface/view 的 pages[].part 获取；生成任务额外携带该名称，覆盖下载器的默认标题，确保历史记录、Markdown 预览和批量导出文件名一致。

标题数据分工

• 历史记录继续使用原有的 audioMeta.title 显示，保持与 ae67b87 一致。
• 新增任务级 favoriteVideo 数据结构，保存每个收藏视频/分 P 的小标题。
• 收藏夹展开列显示该小标题，批量导出 Markdown 时使用该小标题作为文件名；不会覆盖历史记录中的原始视频标题。

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.