feat(backup): add restic backup role with encrypted incremental snapshots

Restic-backed backups using a many-to-many repository/job model.

- repository = destination: restic repository URL verbatim (s3, local,
  removable device), backend credentials via env passthrough, retention
  policy, and an optional per-repository ntfy notify channel
- job = source set: paths, sqlite and postgres dumps (consistent .backup /
  pg_dump instead of torn live-file copies), pushed to one or more repos
- systemd timer per job, per-repo + per-job flock serialisation, restic
  check with read_data_subset for rotating integrity verification

Service roles declare what to back up (ntfy_backup_*, uptime_kuma_backup_*);
the inventory declares where.

roles/uptime_kuma/defaults/main.yml

@@ -6,6 +6,19 @@ uptime_kuma_version: "2"
 # NFS is NOT supported - will cause SQLite corruption
 uptime_kuma_data_dir: "{{ podman_projects_dir }}/uptime-kuma/data"
 
+# Backup manifest - consumed by roles/backup via inventory `backup_jobs`.
+# The uptime_kuma role owns WHAT gets backed up: kuma.db holds every monitor,
+# notification channel and status page, and is a live SQLite file - so it is
+# excluded from the live tree and dumped with sqlite3 .backup instead (copying
+# a live SQLite file yields a torn snapshot, recent writes sit in the -wal
+# sidecar). The rest of the data dir is archived as-is.
+uptime_kuma_backup_paths:
+  - "{{ uptime_kuma_data_dir }}"
+uptime_kuma_backup_exclude:
+  - "{{ uptime_kuma_data_dir }}/kuma.db*"
+uptime_kuma_backup_sqlite:
+  - "{{ uptime_kuma_data_dir }}/kuma.db"
+
 # Network configuration
 uptime_kuma_port: 3300