Volume Restore Fails: Stopped Container Still References Volume, Requires Manual SSH to Restore

To Reproduce

1. Have a Docker Compose service with a named volume
2. Stop the service from the Dokploy UI
3. Go to Volume Backups → Restore and select a backup
4. Trigger the restore
5. Restore aborts with "Volume is in use" even though the container is stopped (exited)

Current vs. Expected behavior

Current: Dokploy stops the container but does not remove it. The exited container still holds a reference to the volume, causing the restore to abort with:

⚠️ WARNING: Cannot restore volume as it is currently in use!
Status: exited
❌ Volume restore aborted - volume is in use

The only workaround is to SSH into the server and manually run docker rm <container_id> and docker volume rm <volume_name> before triggering the restore again.
Expected: The restore process should automatically remove stopped/exited containers referencing the volume before proceeding, making the UI restore fully self-service without requiring SSH access.

Provide environment information

Dokploy Version: v0.28.6 (cloud)
OS: Ubuntu (Hetzner VPS, ARM aarch64)
Docker Version: run docker --version to get yours
Deployment type: Docker Compose with named volume

Which area(s) are affected? (Select all that apply)

Docker Compose, Docker, Cloud Version

Are you deploying the applications where Dokploy is installed or on a remote server?

Remote server

Additional context

No response

Will you send a PR to fix it?

No

Start with the Volume Backups restore flow and its Docker Compose container and volume handling; reproduce the failure using an exited container that still references a named volume. Done means restoring from the Dokploy UI removes eligible stopped or exited references automatically and succeeds without manual SSH cleanup.