feat(backups): add persistent restoration history

[olivier-drieux]

What is this PR about?

Add persistent restoration history under Overview → Restorations so users can follow database, volume and whole-Dokploy restores and reopen their logs after closing the original panel or reloading the page. Restore forms start tracked operations independently of the log viewer and link to service-filtered history. The feature reuses Dokploy's existing layout, components and permissions.

The implementation adds a restoration schema/migration, persisted status and redacted logs, permission-scoped list/log APIs, authenticated log downloads, and recovery of abandoned operations. Cloud recovery uses PostgreSQL-backed heartbeats; whole-instance restores preserve the local journal and reimport it after restoring the database. Previous operations predating the feature are not reconstructed.

This is a draft for maintainer feedback, pending agreement on the feature proposal and the integration checks below. The development fixtures, test launcher and local S3/Docker harness are outside the product repository and are not part of this PR.

Validation completed:

• 44 backup/restoration tests passed, including PostgreSQL-backed permission and concurrency tests; TypeScript and Biome passed.
• The native local Next.js application was checked for navigation, search/status/type filters, reopening logs after reload, log downloads, light/dark themes and mobile layout.
• Actual small-volume restores exercised success, missing S3 object and retry after failure through authenticated APIs, against a dedicated rootless Docker daemon and local authenticated S3-compatible storage.
• All three restored files matched their original SHA-256 hashes; history and unchanged downloadable logs survived an application restart. Downloads returned 401 without authentication, and the tested S3 credentials were absent from logs/errors.
• Independent code reviews found no remaining findings. The integration-harness reviewer could inspect the scripts and saved evidence but could not independently access Docker in its sandbox.

Before marking ready for review: validate actual database and whole-instance restores, large/interrupted restores and a production S3 provider. The integration run's new log entries were verified through APIs; the browser blocked a fresh reload, so those entries still need a visual recheck.

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 http://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)

Feature proposal: #5629

Screenshots (if applicable)

Native local Dokploy preview with seeded test data. The image is hosted on a separate documentation branch of the fork and is not part of this PR's product diff.