[Feature]: VideoProvider 支持 Fal 队列协议，换用 kling-3.0-turbo 并按动作类型定时长 #539

背景

2026-08-21 用同一只鸟、同一张首帧（#511 修复后产出，中灰底、主体占幅 42.5%）、同一条产品提示词，横评了七个视频模型。尺度漂移读数：

人工判定：kling-3.0-turbo 3s 表现最好；veo 更强但单价约 3 倍；kling-v3 std 把「飞」做成了走路；kling-v2-6 出杂物。

两条可复用的结论：漂移随时长单调上升（veo 4s +7% → 8s +21%），所以时长不是越长越好；而首帧主体占幅是前置条件（#511 之前只有 16.2%，模型会自己推镜重构角色）。

问题

现役 kling-v2-5-turbo 在这批里排第四。想换成 kling-3.0-turbo 有一个硬约束：它不在 OpenAI 协议面上。

POST /v1/videos 只认 kling-v3-omni / kling-video-o1 / sora*；kling-3.0-turbo 只在 Fal 队列面 queue/fal-ai/kling-video/v3/turbo/{mode}/image-to-video。而 SufyVideoProvider.i2v 只会说 OpenAI 面那一套（POST /videos + input_reference dataURI + GET /videos/{id} 轮询）。

所以这不是往 ALLOWED_VIDEO_MODELS 加一行就行。

范围

• VideoProvider 支持 Fal 队列协议：submit → 轮询 status_url（IN_QUEUE / IN_PROGRESS / COMPLETED / FAILED）→ 取 response_url 的 video.url → 下 mp4。鉴权是 Authorization: Key，不是 Bearer
• 首帧传法待定：队列面吃不吃 dataURI 没验出来（只给 image_url 不给 prompt 时，合法 dataURI 与非法裸串返回同一个「prompt 缺失」，说明 image 在 prompt 之后才校验）。若只吃公网 URL，则要在调用前把首帧上传对象存储 —— 产品已有这条能力
• 时长按动作类型定，不写死 5 秒：简单循环动作（走路、待机、飞行）3 秒足够且漂移最小；复杂一次性动作（攻击、跳跃）再适当加长。当前 i2v(..., seconds=5) 是写死的
• 时长变短后要核对抽帧密度：3s@24fps = 73 帧，抽 32 帧仍够，但这条要有断言而不是靠巧合
• 不改抠图、对齐、像素化
• 不接 veo / seedance：同一套队列协议做好后它们是加型号的事，但单价高，另议

验收

• 同一只鸟同一首帧，走产品管线用 kling-3.0-turbo 3s 出片，尺度漂移与手工跑的那次同量级
• 队列任务失败（FAILED）时任务落 failed 并解冻积分，不静默留在 running
• 时长由动作类型决定，且有用例钉住「走路取 3s」这类映射
• 现役 kling-v2-5-turbo 仍可用，不因为加了新协议而失效