[BUG] App update flow deletes images before pull succeeds - leaves app broken + stuck "needs update" on any pull failure

Disclaimer: drafted with claude

Describe the bug

The app-update flow tears down the app's containers and images before confirming the new images can actually be pulled. If pull fails for any reason, the app is left with zero containers and zero images, and Runtipi's own "installed version" record is never updated, so the UI keeps showing it as needing an update, on top of it now being completely down.

Observed sequence from runtipi/logs/*.log during an immich update:

Running docker compose ... stop
Moving archive to backup directory...
Updating app immich:falkheiland
Running docker compose ... up --detach --force-recreate --remove-orphans   (still old images)
Running docker compose ... down --rmi all --remove-orphans                 (deletes containers AND imagDeleting app immich:falkheiland folder i
Creating app immich:falkheiland folder / data folder                                                   Copying app immich:falkheiland from repo
Running docker compose ... pull                                                                        Failed to update app immich:falkheiland:: 360.071µs, allowed: 44000/minute

After this, docker ps -a showed no immich containers at all, and none of the four images were present locally. The app stayed down until I manually pulled each image with plain docker pull (which worked immediately, so the parallel docker compose pull across 4 images appears to trip a client-side rate limiter, not an actual registry block from toomanyrequests) and ran docker compose up -d by hand.

To Reproduce

1. Trigger an app update where docker compose pull fails partway (registry hiccup, rate limit, network blip, anything).
2. Observe the app now has no containers
3. Observe the app-store UI still shows "update available" for it, since the job never reached a successful completion state.

Expected behavior

• pull should happen (and succeed) before the existing containers/images are torn down, so a failed pull just leaves the previous working version running.
• If an update does fail, the app should be left in a recoverable state (either rolled back to the prior version or clearly marked as failed/stop stale "needs update" badge).

Additional context

• Also compounded by a separate, already-tracked bug: retrying via ./runtipi-cli app update <id> fails locally with the transient_nonexcl_queues Rabbit), but the backend job keeps running anyway, so CLI-driven retries are confusing to reason about on top of this.
• Using a custom user-config/tipi-compose.yml override, if relevant: yes.

Environment

• Tipi Version: v4.10.1
• Docker: 29.6.1