fix(compose): move atomic backup out of stack folder, silence stale stats 404s (#498)

The Skipper/Admiral atomic deploy/update path used to create
.sencho-backup/ inside the user's stack folder, which silently failed
with EACCES whenever a container had chowned the bind mount (swag,
tautulli, linuxserver/* images, etc). That broke auto-rollback and the
manual rollback endpoint for those stacks. Stack backups now live under
<DATA_DIR>/backups/<stackName>/ next to sencho.db, which is always
writable by the Sencho user.

While stress-testing the same scenario, MonitorService also flooded the
error log with "Error parsing stats for container ... 404 no such
container" because per-container stats polls (30s tick) raced with
docker compose recreating containers. The 404 case is now skipped
silently; non-404 stats failures still log at error level.

docs/features/atomic-deployments.mdx

@@ -11,7 +11,7 @@ Sencho wraps every deployment in a safety net on Skipper and Admiral tiers. Befo
 
 ## How it works
 
-1. **Backup** - Before a deploy or update, Sencho copies your `compose.yaml` and `.env` files to a backup directory inside the stack folder
+1. **Backup** - Before a deploy or update, Sencho copies your `compose.yaml` and `.env` files to a safe internal location
 2. **Deploy** - Sencho runs the requested compose operation (up, pull + recreate, etc.)
 3. **Health probe** - After deployment, Sencho waits briefly, then checks whether any containers exited with a non-zero exit code
 4. **Auto-rollback** - If a crash is detected, Sencho restores the backed-up files and re-deploys automatically