Stems archive: closing the modal silently cancels a live job

[dylanjeffers]

Summary

Closing the download-archive modal cancels the in-flight job. DownloadTrackArchiveModal.tsx:116-121:

const handleClose = useCallback(() => {
  if (jobId) {
    cancelStemsArchiveJob({ jobId })
  }
  onClose()
}, [onClose, jobId, cancelStemsArchiveJob])

The mobile drawer does the same on dismiss.

Impact

Archive jobs are long — a verified healthy 11-stem WAV run took 51s, and multi-GB contest stem sets run for minutes. Combined with the absence of any progress indicator (the missing progress indicator), users reasonably conclude a job is hung and close the modal, which destroys real work that was about to finish. They then start over from zero, re-downloading every stem and re-zipping.

The archiver charges real bandwidth and disk for each attempt, so this is wasteful on both ends.

Proposed fix

Options, roughly in order of preference:

1. Let the job continue in the background and notify when the archive is ready. Best UX, most work — needs somewhere to surface "your download is ready".
2. Confirm before cancelling ("Stop preparing this download?") so dismissal is deliberate.
3. At minimum, don't cancel on incidental dismissals (tap-outside / back) while still cancelling on an explicit Cancel action.

Fixing the progress indicator first would reduce how often users hit this at all.