Bulk downloads scheduled before session expiry are lost: persist per account and replay after re-auth

### Summary

When a user's session expires while bulk-download zips are being prepared, the zips are built server-side but never offered to anyone: their `bulk_download_complete` events fire into the socket of the session that is being torn down, and after re-authentication nothing replays them. The client currently detects the situation and shows a finite "downloads interrupted, please re-run" toast (see the expiry handling in `bulkDownloadQueryFn`, `invokeai/frontend/web/src/services/api/endpoints/images.ts`), which is honest but still loses the work.

### Proposed fix

Persist scheduled bulk-download jobs per account (item name + requesting user), and on (re-)authentication replay pending completions to the user's fresh socket — at which point the "preparing"/"ready" toast flow can resume instead of asking the user to re-run the download. This also covers the narrower window where a zip completes between socket teardown and reconnect.

### Context

Raised by @JPPhoto in review of #9394 ("Consider persisting download jobs by account and replaying them after re-authentication; this eliminates expiry-induced zip loss and stuck preparation toasts"). #9394 bounds the client-side damage (correct toasts, no permanent "preparing" banner, no payload leaking across sessions); this issue tracks the recovery half.