转录预算对零/偏小时长无下限守卫：duration=0 会算出 120 秒预算，确定性掐断本来能成功的任务 #190

结论

capswriter_client.py 的 _transcription_deadline（:254-260 附近）对 media_duration 只拒绝负数（media_duration < 0），0 与偏小时长被接受，预算公式给出 0*4+120 = 120 秒。直播录制容器（FLV/TS 流式封装）的头部 duration 为 0 或明显偏小是常见现象——届时一个在 SDK 自动预算下本可成功的任务，会被确定性提前掐断，且只有一行 WARNING，无用户可见差异。紧邻本仓 P1 红线「静默出错」。

证据

• _transcription_deadline 判据：media_duration is None or not isfinite or media_duration < 0 → fallback；0 直通。
• _finite_time_or_none（:424）对 0 也返回 0 而非 None，不构成兜底。
• 对照：SDK _auto_budget docstring 明确写「时长为 0 或短音频时仍不低于 120 秒」——SDK 是刻意保底，本仓显式路径反而把 0 当真。

修法（一行 + 一条测试）

media_duration < 0 改 media_duration <= 0（或加合理下限如 1 秒），退化输入按 unknown 走 fallback=sdk_auto，与修复前行为一致。补一条 duration=0 → 返回 None 的单测。

边界

• 出处：issue-triage consult（claude-opus，2026-10-06）对 generic/recorder:// 下载路径不写 last_media_duration，时长预算机制对该来源恒失效（静默） #170 的残余风险分析；主脑已核实代码事实。
• 不与 fix: 时长探测在 generic/recorder 路径失效——复用准入探测结果供转录预算使用 #173 已合并的改动混在一起；本单是 generic/recorder:// 下载路径不写 last_media_duration，时长预算机制对该来源恒失效（静默） #170 预算机制在该来源上的残余缺口。
• 真实 recorder 产物能否拿到正确 duration 未核实——但 <= 0 防御本身无害（合法媒体时长不会是 0），不依赖该核实即可落地。