Add the TapDB backup and recovery lifecycle (#89)

[jdurham38]

Closes #89.

Replaces the previous ~140-line five-table backup command with a schema-scoped,
checksummed, manifest-described backup subsystem driven by one shared service
across CLI, admin API and the embedded GUI, so a fix to how backups are taken is
a fix everywhere at once.

What it delivers

Three backup classes (template-pack, full logical, provider-snapshot receipt).
Restores default to an isolated target; in-place requires a typed confirmation
and lands via a verified staged schema swap, so nothing is dropped until a
verified replacement exists and every failure path renames the original back.
Integrity is verified before and after, which is what makes EUID reuse
impossible. Every mutating run emits an immutable hash-chained receipt with a
head anchor, so truncation is detectable rather than merely unlikely.

All 10 issue items are complete

• tapdb backup prune: retention enforcement. A backup is deletable only
  when its hold set is empty: nothing is ever selected for deletion, things
  fail to be protected. Fourteen holds behind seven gates that abort before a
  single byte is removed. Dry run is the default; deleting needs the typed target
  label, and a delete ceiling guards the case where that label has become a
  constant in a scheduled job.
• tapdb backup health: the alerting contract. Exit 0 recoverable, 1
  something is wrong, 2 the check itself could not run, with parseable JSON on
  stdout on every code. The runbook documents cron/systemd/monitor wiring.

Please note

A live bug fix rode along. S3StorageBackend.list_keys built its Prefix
without a trailing delimiter, so listing acme/orders also returned
acme/orders-staging, inflating backup list, the status page and the GUI with
another target's backups. Unrelated to #89, S3-only, and invisible to existing
tests because local storage has a real directory boundary.

data backup / data restore are now deprecated in favour of tapdb backup.

Verification

1620 passing, 14 skipped. ruff, format and bandit clean. 91.5% coverage against
an 85% gate. Verified e2e against a real Aurora PostgreSQL 16.11 cluster.

Testing leaned on mutation testing throughout, deliberately breaking each
guarantee and confirming a test fails. That is what caught the defects a green
suite was hiding, including EUID reuse after in-place restore, CLI exit codes
reporting 0 for failures, and a prune reconciliation path that could erase an
entire store from a single unvalidated receipt field.

One thing

• No tag yet. setuptools_scm already derives 9.0.11.dev1. Tag 9.0.11
  on the merge commit when something actually needs to pin it. 9.0.10 and every
  earlier tag are untouched, and no service pins a mutable ref, so nothing
  downstream moves.

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of lines (20,000). Try reducing the number of changed lines and requesting a review from Copilot again.

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of lines (20,000). Try reducing the number of changed lines and requesting a review from Copilot again.