feat(tasks): add governed retry and recovery semantics for failed tasks

[chuanxu742-glitch]

产品问题

Dashboard 在失败状态下提示用户“先查看失败原因，再决定重试”，任务详情也将异常区域命名为“需要处理”；但当前任务详情没有任何恢复动作，/tasks API 也只有通用 POST /tasks/trigger，没有针对失败任务的受控重试语义。

直接复用 trigger 并不等同于重试：它会创建一个没有重试血缘的新 manual task，且采集管线可能继续触发通知、共享 Plan segment 或其他下游副作用。用户无法判断这是“重试同一次意图”还是“发起一次全新运行”。

当前证据

• Dashboard 文案明确出现“决定重试”。
• Task detail 只提供“查看数据源 / 检查数据成果 / 查看控制与审计”。
• backend/api/v1/tasks.py 没有 retry/rerun/resume endpoint。
• CollectionTask / TaskRun 没有 retry lineage、operation key 或 recovery decision 字段。
• 通用 trigger 会重新经过 collection pipeline 与下游 dispatch。

建议产品契约

• 仅允许对终态失败任务发起受控恢复；运行中、等待中任务拒绝重复提交。
• 恢复创建新的 Task/Run 并保留原失败历史，不原地覆盖状态。
• 新任务记录 retry_of_task_id / recovery reason / initiating actor，并在 UI 展示血缘。
• 在执行前明确影响范围：仅重新采集、重新处理，还是允许重新交付。
• 对可能产生外部副作用的阶段复用稳定 Operation ID 或显式跳过已成功阶段，禁止盲目重复发送。
• API 接受幂等键，重复点击返回同一恢复任务。
• Task detail 显示确认、pending 状态、成功/失败反馈，并跳到新的任务上下文。

验收建议

• failed task 可安全发起一次恢复；重复请求不会创建多个业务意图。
• disabled/deleted source、非终态 task、已在恢复中的 task 均有明确错误。
• 原 task/run/events/records 不被改写。
• 测试覆盖本地 executor、Celery dispatch 失败、重复请求和外部交付保护。