fix(generation): 待机按 32 帧生成，帧数被当成前端阶段判据

[johnnyzhang-eng]

现象

所有动作都按 32 帧生成，待机也是。待机是原地小幅呼吸，32 帧里绝大多数帧之间几乎没有差别，多出来的帧既不提升观感也进不了引擎的有效循环，却照样占抽帧、抠图、对齐、上传的工作量与存储。

现状

32 不只是一个默认值，它同时被当成前端识别任务阶段的判据：

• orchestrator/model.py:76 num_frames: int = 32
• web/api/generation.py:195 num_frames: int = Field(default=32, ge=1, le=64)
• frontend/src/entities/generation/api.ts:521 提交时写死 num_frames: 32
• api.ts:312-317 校验 num_frames !== 32 直接抛错
• api.ts:333 inferExpectation 靠 num_frames === 32 才认得出这是完整动画任务，否则抛「无法映射到前端阶段」

因此把待机改成 16 帧，会让前端把这类任务判成无法识别，不是改一个默认值就能完成。

方案

按动作类型给出各自的帧数，前端不再以帧数作为阶段判据。

1. 后端按 action_type 给默认帧数，待机取 ≤16；请求显式传值时以请求为准。
2. 前端提交时按动作类型取对应帧数，不再写死 32。
3. inferExpectation 改用 task_type 与 action_type 判断阶段，不再依赖帧数取值。
4. 校验从「必须等于 32」改为「与该动作类型的约定一致」。

不包含

• 不调整其他动作的帧数。走路与攻击目前没有观察到同类问题，一并改会让「待机变好」与「其他动作变了」混在一起。
• 不改变抽帧算法本身。

需要对齐

待机的具体帧数取 8、12 还是 16。这决定循环的顺滑程度与成本，属于产品口径。

验收

1. 提交待机动作时，任务的 num_frames 不再是 32。
2. 前端能正确识别帧数不为 32 的动作任务，不再抛「无法映射到前端阶段」。
3. 有一条测试锁住「待机任务的帧数取该动作类型的约定值」。