Feat(backend): Add improved download manager with pause/resume partial download.

[DustyShoe]

Summary

This PR adds few cool things:

• Adds pause/resume for model downloads with proper “restart required” handling when servers refuse Range.
• Persists install state so downloads can resume across restarts using the same temp folder.
• Multi‑file installs now run sequentially per job (one file at a time) for more stable resume behavior.
• Adds restart actions (job‑level and file‑level) plus clearer inline status in the UI.
• Progress bar now aggregates job‑level bytes so it reflects total download progress during multi‑file installs.

Parts of this code were written with assistance, so I’d appreciate any fixes or improvements.

QA Instructions

It might be better to run this with debug logging enabled.

1. Start a multi‑file model install (e.g., Tongyi-MAI/Z-Image-Turbo).
2. Verify progress bar increases and tooltip shows X / Y for the full job.
3. Pause the download mid‑file, then resume.
4. Confirm the download continues (not restarted) and bytes increase from the same point.
5. Kill/restart backend while a download is paused; verify it resumes on start.
6. Force a resume‑refused case (server returns 200 to Range) and confirm:

• file shows “Restart required”
• job status becomes Paused
• “Restart file” works and only that file restarts

8. Cancel a job and re‑install the same model; ensure a new temp folder is created and no old partial blocks it.

Merge Plan

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Tests added / updated (if applicable)
• ❗Changes to a redux slice have a corresponding migration
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)

[JPPhoto]

@DustyShoe Does this handle the case where the user pauses and either:

1. Quits Invoke and deletes the temporary file?
2. Keeps Invoke running and deletes the temporary file?

[DustyShoe]

@JPPhoto Ofc. you had to find worst case scenario...

1. Why user even do that?
2. User pauses, quits Invoke, deletes temp file
   On resume, we look for the .downloading file. If it’s gone, resume_from=0 and we start a fresh download (no resume).
3. User pauses, keeps Invoke running, deletes temp file
   The file is already closed on pause, so deleting it is fine. When the user resumes, same as above: no .downloading file, so it restarts from scratch.

[JPPhoto]

@DustyShoe We can't predict what users or their systems will do, so coding defensively and being resilient (to a point) is always good.

[DustyShoe]

@JPPhoto Have to admit, that was a good point actually. Went back and added explicit toast message if temp file was removed and user tries to restart download. Also there was a bug in status bar updating. It did never reset to 0 in that case.