ix(database-backup): drop bogus --single-transaction flag from pg_dump

pg_dump rejects `--single-transaction` — it's a pg_restore / psql flag,
never a pg_dump one. Triggered as soon as the inline-dump path landed
on Ralf's install:

  pg_dump: unrecognized option: single-transaction
  pg_dump: hint: Try "pg_dump --help" for more information.

pg_dump already wraps the entire export in a single REPEATABLE READ
snapshot automatically (since Postgres 9.x), so the original intent —
consistent snapshot of the live DB — is preserved by removing the
flag. Same "latent until Stage A wired it in" pattern as the three
prior bugs this rollout has surfaced (PG insert destructure → bind-
mount EACCES → Node 22 stdio strict mode → this).

backend/src/services/databaseBackup.js

@@ -206,12 +206,20 @@ class DatabaseBackupService {
       '--format=plain',
       '--encoding=UTF8'
     ];
-    
-    // Add transaction support for consistency
-    if (!options.noTransaction) {
-      pgDumpOptions.push('--single-transaction');
-    }
-    
+
+    // NOTE: do NOT add `--single-transaction` here. It looks like
+    // the right flag for "consistent snapshot" but it isn't a pg_dump
+    // option — it belongs to pg_restore / psql and pg_dump rejects it
+    // with `unrecognized option: single-transaction` (exit code 1).
+    // pg_dump already wraps the entire export in a single REPEATABLE
+    // READ snapshot automatically (since Postgres 9.x), so consistency
+    // is built in. If we ever need stricter cross-pg-cluster snapshot
+    // sharing, use `--snapshot=<id>` — but the typical inline-dump
+    // path doesn't need it. Bug went undetected until Stage A wired
+    // this code into the user-facing "Run Backup Now" path; prior
+    // callers (scheduled cron, dedicated admin DB-backup page) hit
+    // the same failure but on installs that had never exercised them.
+
     // Add compression if not doing it separately
     if (options.compress && !options.separateCompression) {
       pgDumpOptions.push('--compress=6');