Resume uploads after a crash or reload (durable upload queue) #79365

What problem does this address?

#74366 adds retry logic and offline handling so an in-progress upload can recover from transient network failures. However, the upload queue currently lives only in memory. If the browser tab is closed, the page is reloaded, or the browser/OS crashes mid-upload, all queued and in-progress uploads are lost and the user must start over.

Anne specifically called out making uploads "resume after a crash or going offline" for the 7.1 cycle. The "going offline" half is addressed by the retry work in #74366; this issue covers the missing half: durable resume after a crash or reload.

Proposed approach

Persist the upload queue to durable storage (e.g. IndexedDB) so it survives a reload/crash:

• Persist pending and in-progress queue items (file data + processing/upload state)
• On editor load, detect an interrupted queue and offer to resume (or auto-resume)
• Resume from the last completed pipeline step where possible, rather than restarting
• Clean up persisted entries on completion/cancel and bound storage usage

Acceptance criteria

• Upload queue state persists across page reload and browser crash
• Interrupted uploads are detected on next editor load and can be resumed
• Resume continues from the furthest completed step (processing vs. upload) where feasible
• Persisted data is cleaned up on success/cancel; storage is bounded
• Graceful behavior when durable storage is unavailable (fall back to current in-memory behavior)
• e2e coverage for the reload/resume flow

Complements the retry/offline work in #74366. Part of #76756.