[1028huli]

改动概述

抖音转写改为从实际视频提取音轨，避免把独立配乐当成完整口播。旧任务重试时备份并停用旧音频元数据和转写缓存。

为什么

现有下载器读取 aweme_detail.music.play_url.uri。该资源可能只是配乐，与视频最终混合音轨不同，导致遗漏人声或产生重复、无关的转写。

本地复现中，配乐资源约 100 秒，转写仅返回 4 段 Thank you.；实际视频音轨约 85.6 秒，同一 Faster Whisper large-v3-turbo 模型直接读取 MP4 后得到 43 段中文口播。该对比用于验证音频来源问题，不代表转写已逐字校对。

做了什么

• 复用 download_video 和已有 LocalDownloader.convert_to_mp3，从视频提取音轨。
• 音频使用独立的 _video_audio.mp3 文件名，保留旧配乐文件；返回实际 video_path。
• 用 raw_info.audio_source=video_track_v1 标记新来源。
• 读取转写缓存前，备份没有新来源标记的抖音音频元数据及转写缓存；已使用正确音轨的缓存继续复用。
• 补充回归测试和 CHANGELOG。固定间隔抽帧、拼图、其他平台下载流程均不在本 PR 范围内。

测试方式

• 针对性测试：python -m pytest -q tests/test_douyin_audio_source.py tests/test_whisper_config_forwarding.py（backend 目录）。
• 修改的 Python 文件编译检查通过。
• 本地实际 MP4 的 FFmpeg 音轨提取成功，输出约 85.6 秒；直接转写视频得到中文口播。
• 上游干净环境的在线抖音下载 → 转写 → LLM 端到端验证尚未执行；本地下载链路还包含另行开发的签名修复，不纳入本 PR。

回归风险

• 即使只需要转写，也需要下载实际视频，增加网络流量和磁盘占用，并依赖已有 FFmpeg。
• 旧抖音任务首次重试会重新转写；旧缓存以唯一 .legacy-music-*.bak 文件保留，不自动清理。
• 已完成历史结果不会被后台批量改写，需要用户重试任务。
• 不修复既有抖音登录/签名/防盗链问题，也不保证所有视频的转写准确率。

Checklist

• 分支使用 codex/douyin-video-audio。
• base 使用 master：检查时上游无 develop 分支。
• Commit message 使用 fix(douyin): ... 格式。
• 已更新 CHANGELOG。
• 不包含 Cookie、密钥、环境文件、视频、模型或运行数据。
• 仅涉及本次后端修复及文档。