Fix #1038: cancel in-flight chapter-video downloads on delete/replace

[sampjvv]

Closes #1038.

Problem

While a chapter video is downloading ("Get video → Load/Save to project"), deleting or replacing it doesn't stop the download. The fetch runs to completion in the background and writes the bytes to files/, resurrecting the video the user just deleted.

Root cause

downloadVideoToProject / downloadVideoToSessionCache (videoDownloadUtils.ts) fetch the whole LFS object via authApi.downloadLFSFile with no AbortController, then writeFile unconditionally. The in-flight tracker was a plain Set (no way to cancel), the delete/replace handlers never signalled it, and the download progress was cancellable: false.

Fix

• In-flight tracker → Map<string, AbortController>. beginVideoOperation returns the controller; new abortVideoOperation() cancels it.
• Both downloaders accept a signal, pass it to downloadLFSFile (its type already accepts one), and guard the write with signal.aborted — so even if the downloader ignores the signal, the deleted file is never rewritten.
• deleteVideoFile and the metadata replace path call abortVideoOperation(...) before removing the file.
• The "Saving/Loading video…" progress is now cancellable and wired to abort (a user cancel no longer pops an error).

Scope decision

The streamed <video> path is intentionally unchanged. It self-limits — the browser buffers a chunk, goes idle, and releases on GC — so there's no equivalent background-load leak to fix there. (Verified by instrumenting the element's networkState/buffered live.)

Verification

• Unit (6): the cancellation contract — abort propagates to the signal, re-begin supersedes without leaking, ops scoped per workspace+video.
• Integration (3): drives the real downloadVideoToProject against a temp workspace + LFS pointer with a mocked, abortable downloadLFSFile:
  • control — no abort → bytes are written (harness is genuine);
  • delete + abort mid-download → file stays deleted, even when the downloader ignores the signal (the core guarantee);
  • signal-honoring downloader → also stays deleted.
• Frontier source confirmed (genesis-ai-dev/frontier-authentication): downloadLFSFile forwards the AbortSignal through downloadLFSObject (refcounted) into the underlying fetch, so the network request is genuinely cancelled — a shared object download stops once the last waiter aborts.
• Live GUI: in a synced, stream-only project, started "Get video → Save to project" and deleted the video mid-download — the file was not resurrected.
• tsc --noEmit + eslint clean. The targeted videoDownloadUtils suite is 9/9.

Note: the full local extension-test run currently hangs in an unrelated, pre-existing E2E test (E2E: Timer Management / Timer During Sync, project-swap timers) that runs before — and independently of — these video tests; the same changes passed the full suite (1202 passing / 0 failing) before rebasing onto current main. CI runs the authoritative suite.

🤖 Generated with Claude Code

[LeviXIII]

There are a couple of places and scenarios where the cancel button is missing. If we try to save or load the video to the project from pressing the Show Video button, the cancel button is missing in that flow. There is also the scenario where the video is missing. If we try to download it, it will try to retrieve it, but we should be able to cancel from there as well.

[sampjvv]

@LeviXIII Both missing-cancel scenarios are fixed in f69fe30. They turned out to share one handler: the Show Video → "Save to project"/"Load for session" buttons and the missing-video "Download & play" button all post downloadVideoFile, whose progress toast was the one video download still cancellable: false.

• That progress is now cancellable, and the fetch is registered in the same in-flight registry as the sidebar flow — so a cancel or deleting/replacing the video mid-download aborts it (the delete-abort previously only covered the sidebar downloads). Cancel resets the player quietly ("Download cancelled." + Retry), no error toast.
• Also sealed the write race: a cancel that lands while the verified bytes are being written now reverts files/ to the exact pre-download pointer stub (or removes the file/cache entry if none existed). The abort check brackets the write in all three write sites (handler + both nav utils), and it's the last statement inside the progress callback — so any cancel that can physically be clicked is honored; no window where a cancel is silently ignored and a video stays saved.
• Two new deterministic write-race tests (abort fired during the fs write): stub restored byte-identical / file removed when no stub pre-existed. 11/11 videoDownloadUtils tests green.

Verified in the app: stream-only → Show Video → Save to project, and stream-and-save → Download & play — both show Cancel; cancelling mid-download leaves files/ as the pointer stub.