Archive the whole data volume in Backups, not just the database

Settings > Backups gains a whole-data archive beside the database
snapshots, and both lists now fully work from the page.

- Data archives: `write-data-backup-archive.ts` tars all of DATA_DIR into
  BACKUP_ARCHIVE_DIR as cobble-data-<epoch-ms>.tar.gz, every entry under one
  root folder named after the archive, writing a .part name and renaming on
  success so a cut-off run is never listed. The newest
  AppData.DataBackupsKept are kept; db/.backups is left as it is.
- Restore: `restore-data-backup.ts` extracts to a temp dir, requires one
  root folder holding a db folder, takes a safety archive first, then
  replaces DATA_DIR (the database snapshots included) and `restart-app.ts`
  restarts the process through the docker socket, since the open SQLite
  handle points at the replaced file.
- Upload and restore: a modal over each list (database file or data
  archive), replacing the old /admin/settings/backups/restore page.
- Delete for both kinds, icon-only row actions shared through
  RowIconButton, and restore on every row.
- One backup or restore of either kind at a time (with-backup-run-lock).
- BACKUP_ARCHIVE_DIR is a start-up path (ProcessOnlyEnvKeys); the installer
  mounts $COBBLE_HOME/backups-archives at /backups-archives and recreates a
  container that lacks it. The image installs tar and gzip.

src/functions/backend/backups/create-data-backup.ts

@@ -0,0 +1,21 @@
+import withBackupRunLock from "./with-backup-run-lock";
+import writeDataBackupArchive from "./write-data-backup-archive";
+
+/**
+ * Archives the whole `DATA_DIR` (database, media, computer homes, bot and
+ * workspace files, MCP installs) into `BACKUP_ARCHIVE_DIR` as
+ * `cobble-data-{timestamp}.tar.gz`, then keeps only the newest
+ * `AppData.DataBackupsKept`. Every entry sits under one root folder named
+ * after the archive (`cobble-data-{timestamp}/`), so extracting it lands
+ * one folder, never a heap of files in the current directory. The
+ * database's own snapshots in `db/.backups` are inside `DATA_DIR`, so they
+ * ride along and are left alone on disk.
+ *
+ * The archive is a filesystem copy of a live volume, so the SQLite file
+ * inside it is only as consistent as the moment tar read it; a consistent
+ * database snapshot is what the `db/.backups` list is for. Restoring a
+ * whole-data archive is `restoreDataBackup` (`restore-data-backup.ts`).
+ */
+export default async function createDataBackup() {
+    return await withBackupRunLock({ task: writeDataBackupArchive });
+}