feat(server-ops): automate backup restore verification

[Adamskiee]

Problem

#337 automates taking database backups, but a backup that "succeeded" (dump file written, no error) is not the same as a backup that is actually restorable. A truncated, corrupt, or schema-mismatched dump looks identical to a good one until someone tries to restore it — and today that only happens during a real incident, per runbooks.md#backup-and-restore-mariadb. That's the worst possible time to discover the backup was bad.

This was explicitly called out of scope in #337 as a separate concern (restore stays operator-driven/manual during a real incident; this issue is only about verifying, not performing, an incident restore).

Proposed scope

• A scheduled job (systemd timer, same pattern as the backup automation in feat(server-ops): automate MariaDB backups (scheduled dump, retention, off-host copy) #337) that periodically:
  1. Takes the most recent dump produced by the backup job.
  2. Restores it into a throwaway MariaDB instance or an isolated test schema (not the production database).
  3. Runs a sanity check against the restored data (e.g. row counts on key tables, mysqlcheck, or a checksum comparison) to confirm it's structurally and quantitatively sound.
  4. Reports pass/fail somewhere observable (journald, consistent with how the other server systemd units are monitored per monitoring-logging.md).
• On failure, the signal needs to be loud enough that an operator notices before the next real incident — at minimum a clearly-flagged log entry; consider whether this warrants a state file or /health-style endpoint check per the existing observability conventions.
• Update runbooks.md and maintenance.md to document the verification job and what to do if it reports a failure (essentially: treat it as the backup job failing, re-run/investigate immediately rather than waiting for the next cycle).

Out of scope

• Restoring to the actual production database during a real incident — that stays a deliberate, manual, operator-driven step per the runbook.
• The backup-taking automation itself (tracked in feat(server-ops): automate MariaDB backups (scheduled dump, retention, off-host copy) #337 — this issue depends on it).

Acceptance criteria

• Verification job runs on a schedule without operator action, restoring into an isolated instance/schema (never production).
• Job checks restored data for structural/quantitative soundness, not just "restore command exited 0."
• Failure is surfaced clearly and promptly (observable log/alert), distinct from routine success.
• docs/deployment/runbooks.md and maintenance.md updated with the verification process and failure-response steps.
• Depends on feat(server-ops): automate MariaDB backups (scheduled dump, retention, off-host copy) #337 (backup automation) landing first.