fix(quick-video): no reanudar batches cancelados tras un reinicio

[cursor]

Un lote de Quick Video en cancelling se persistía así si Cancel coincidía con un cierre, crash o reinicio. recover() trataba cancelling como estado activo, lo reescribía a queued y arrancaba un worker. El usuario había pedido parar; el lote volvía a gastar GPU.

Qué cambia

• Tras un reinicio, un checkpoint cancelling se finaliza como cancelled y no relanza el worker.
• Los ítems planning/running de ese lote también quedan cancelled.
• Los lotes queued/running interrumpidos siguen recuperándose como hasta ahora.

Cómo reproducir

1. Lanzar un lote overnight de Quick Video.
2. Pulsar Cancel (status cancelling) y cerrar/matar el proceso antes de que el worker persista cancelled.
3. Al reabrir, GET /api/v1/stories/quick-video-batches (o el recover de arranque) reencolaba el lote.

Validación
pytest tests/test_quick_video_batches.py — 11 passed.

  

---

Note

Medium Risk
Touches durable job recovery and cancel semantics; a mistake could either skip legitimate restarts or still relaunch cancelled GPU work. Scope is a small, well-tested branch in recover().

Overview
Stops overnight Quick Video recovery from treating a persisted cancelling checkpoint as an interrupted run. After a crash or restart mid-cancel, recover() now finalizes the batch (and in-flight planning/running items) as cancelled, publishes that snapshot, and does not start a worker.

queued/running jobs still get the existing interrupt-and-requeue path. A regression test seeds a stale cancelling checkpoint and asserts listing does not relaunch GPU work.

^{Reviewed by Cursor Bugbot for commit ccbe754. Configure here.}

[cursor]

Risk: medium. Left a non-blocking comment: Bugbot and Security Agent completed with no findings, but GitHub blocks this automation from approving a Cursor-authored PR. Assigned IAnMove for human approval.

  

_{Sent by Cursor Approval Agent: Pull Request Router and Approver}