fix(server): fix MongoDB compose restore gzip filename mismatch

[surajmgr]

What is this PR about?

Fix MongoDB restore failure for Docker Compose deployments where restore attempted to unzip backup.sql.gz even when the downloaded file had a timestamped name.

Root cause
Compose restore did not pass backupFile into getRestoreCommand, so Mongo restore used a fallback filename (backup.sql.gz) that often did not exist.

Changes

• Pass backupInput.backupFile from compose restore into getRestoreCommand.
• In Mongo restore command, fallback to detecting the downloaded *.gz file in /tmp/dokploy-restore when explicit filename is missing.
• Add clear failure if no archive is found.

Checklist

Before submitting this PR, please make sure that:

• You created a dedicated branch based on the canary branch.
• You have read the suggestions in the CONTRIBUTING.md file https://github.com/Dokploy/dokploy/blob/canary/CONTRIBUTING.md#pull-request
• You have tested this PR in your local instance. If you have not tested it yet, please do so before submitting. This helps avoid wasting maintainers' time reviewing code that has not been verified by you.

Issues related (if applicable)

closes #3789

Screenshots (if applicable)

Greptile Summary

This PR correctly fixes the root cause of MongoDB restore failures for Docker Compose deployments. The changes are:

1. compose.ts: Now passes backupInput.backupFile to getRestoreCommand (previously omitted), which was the direct cause of Mongo restore using an incorrect fallback filename.

2. utils.ts: Improves the shell script logic with better error handling:

   • Extracts just the filename from the full path
   • Checks if that file exists first
   • Falls back to searching for any .gz file in the temp directory
   • Returns a clear error message if no archive is found

The root-cause fix directly addresses the stated issue. The identical rclone copy pattern is already used in mongo.ts (which works in production), providing confidence that the fallback logic is sufficient.

Confidence Score: 5/5

• Safe to merge. The root-cause fix is correct and directly addresses the stated issue. The improved error handling is logically sound and an improvement over the previous hardcoded fallback.
• The one-line fix in compose.ts correctly addresses the root cause where backupFile was not being passed to getRestoreCommand. The utils.ts improvements add robust error handling with proper shell script syntax. The code pattern is identical to mongo.ts which operates in production, providing confidence in the fallback logic. All changes are focused and targeted to the specific issue reported in MongoDB restore failed with gzip: backup.sql.gz: No such file or directory Error #3789.
• No files require special attention

_{Last reviewed commit: b4079da}

_{(2/5) Greptile learns from your feedback when you react with thumbs up/down!}

Context used:

• Rule used - AGENTS.md (source)