v1.23.0 — Recover --rm containers lost during update

Critical data-loss fix. Reported by @famewolf in #2: his homarr container disappeared entirely during an update. Our first triage said "probably Docker daemon cleanup, not us." That was wrong — and we proved it by reproducing the exact mechanism on a test host.

The mechanism

1. A --rm (AutoRemove=true) container that's slow to stop (homarr was wedged — our stop ran into the 90s timeout)
2. Our docker stop eventually reaps the process
3. Because --rm is set, Docker auto-removes the container the instant it stops
4. Our docker kill fallback then reports cannot kill container: … No such container — the exact error family @famewolf saw
5. The old code hit if not stop_ok: return False and walked away, leaving him with no container — even though we had its full inspect config in memory the whole time

The fix

We capture the container's config before stopping (we always have). Now: after the stop step we check whether the container still exists. If it vanished (the AutoRemove case), we recreate it directly from the captured config — the old container is already gone, so we skip the rename/rollback machinery and run the new one.

homarr would have been updated correctly instead of deleted.

Verified end-to-end on a test host: a wedged --rm container that vanishes on stop is now recreated with all labels and config preserved.

Honesty note

The first triage concluded "probably not us." When a user reports data loss during one of our operations, the burden is on us to prove we weren't involved, not to assume it. The empirical reproduction here came directly from re-investigating under that assumption.

Still open (confirmed, shipping separately)

• "Update all" on a stale notification updates whatever is currently pending, not the set shown in that notification. Snapshot fix coming.
• Bot is slow to respond to SIGTERM because it blocks in the Telegram long-poll. Fix coming.

Upgrade

docker pull amayer1983/docksentry:latest
docker compose up -d