fix(restore): set was_successful=true on the completed update

Caught during the round-4 e2e validation on real PG: every
successful restore landed with `status='completed', was_successful=false`
because the success-branch update only wrote `status` but not
`was_successful` (column default is false). Visible side effect: the
BackupDashboard's "last successful restore" filter would skip the
row + any future audit query gating on was_successful would miss it.

One-line cure: include `was_successful: true` in the success-branch
update payload. Inline comment explains why and references the
review note so future edits keep the two fields together.

Source-inspection test in restoreService.pgBranch.test.js pins the
contract: after `performPostRestoreVerification(...)`, the
`status: 'completed'` update payload must also contain
`was_successful: true`. Future refactors of the success payload that
drop the flag fail the test before merge.

36/36 backup-related integration tests pass.

backend/src/services/restoreService.js

@@ -326,6 +326,15 @@ class RestoreService {
       await db('restore_runs').where('id', runId).update({
         completed_at: endTime,
         status: 'completed',
+        // Default for the column is `false`. Without this line, every
+        // SUCCESSFUL restore ends up with `status='completed',
+        // was_successful=false` — which the BackupDashboard "last
+        // successful restore" widget then filters out, and any future
+        // audit query that gates on was_successful misses the row
+        // entirely. Cosmetic but enough to mislead an operator
+        // scanning restore history. Catches Ralf 2026-06-01 + maintainer
+        // PR #596 review note about the cosmetic.
+        was_successful: true,
         duration_seconds: durationSeconds,
         pre_restore_backup_path: this.preRestoreBackupPath,
         statistics: JSON.stringify({