[Bug] YouTube bootstrap 任务会卡在 in_progress，MV3 service worker 休眠后无超时回收

[elvafan2021]

环境

• 后端 v0.3.207，Chrome MV3 扩展

现象

把 OPENBILICLAW_YT_BOOTSTRAP_SCROLL_ROUNDS 调到 30 后（任务耗时变长），YouTube bootstrap_profile 任务被扩展 claim 后长期卡在 in_progress（claimed_at 有值、completed_at 为空），fetch-youtube 等到 300s 超时也等不到结果。此后：

• GET /api/sources/yt/next-task 一直返回 204 No Content（因为有一个 in_progress 任务占着），新的 YouTube 任务无法再被领取；
• 必须手动进 SQLite 把该任务 status 改成 failed 才能恢复。

推测根因

任务耗时变长后，Chrome MV3 的 service worker 进入休眠，扩展 yt-task-dispatcher.ts 里 armTaskTimeout() 用的 setTimeout 不再触发，任务没有超时回收；后端也没有对 stale in_progress 任务的恢复机制。

建议

• 后端增加 stale in_progress 任务回收（超过阈值自动置 failed / 释放）；
• 扩展侧用 chrome.alarms 替代 setTimeout 做任务超时，避免 service worker 休眠导致定时器丢失。

[whiteguo233]

已修复并合入 main（c7a2defe，分支 fix/issue-178-yt-stale-task-timeout）。

根因
Chrome MV3 service worker 休眠后，扩展 yt-task-dispatcher.ts 里 armTaskTimeout() 的 setTimeout 不会触发，任务超时回调丢失；后端也没有主动把 stale in_progress 任务置终态，队列被一条死任务长期占住。

修复

• 后端 YtTaskQueue 新增 expire_stale_in_progress()：超过 OPENBILICLAW_YT_STALE_IN_PROGRESS_SECONDS（默认 600s）的 in_progress 任务自动置 failed 并写入 completed_at；带 _openbiliclaw_terminal_status 的 staged 结果不覆盖，仍走 stale-reclaim 修复投影。/api/sources/yt/next-task 领取前与 enqueue_yt_bootstrap 入队前都会先回收；next_pending() 同时把 claimed_at IS NULL 的旧 in-progress 行纳入可重领范围。
• 扩展侧任务超时改用 chrome.alarms 一次性 alarm（when: deadline_at），并把 {task_id, deadline_at, tab_id} 写入 chrome.storage.session（不可用时回退 chrome.storage.local）。alarm 触发或 worker 重启后检测到持久化记录时，回传 task_timeout / service_worker_restart 终态、关闭孤儿 tab 并清理本地状态。

验证

• 后端单测 + API 测试：test_yt_tasks / test_api_yt_ingest 全部通过；mypy src/ 与 ruff 通过。
• 全量 pytest：8488 passed, 60 skipped；唯一失败 test_trigger_manual_refresh_sets_running_state 为时序抖动，单测重跑通过，与本次改动无关。
• 扩展 npm run typecheck 通过，npm test 1408 passed。
• 真实环境真实 HTTP E2E：openbiliclaw serve-api + 真实 SQLite + curl，复现「stale in_progress 占住队列」后，再次 GET /api/sources/yt/next-task 成功将该任务置 failed 并返回 204；随后新任务可正常领取、回传终态并完成。

关闭此 issue。