fix(recovery): the database dumps count in the keys the backups still need

The recovery kit, "Keys the backups still need" and safeToDropRetiredKeys
read only the stored copies and the off-host account objects. After a
rotation the page called the old key safe to drop while every dump taken
before it, the pre-migration dumps that are the way back from an update
among them, could only be restored with that key: db-restore refuses a dump
whose active key is missing.

A dump now counts for the key its rows were written under, the manifest's
active key: a dump on this server while it is kept (read from the manifests),
an off-host one until the bucket's rule for database/ expires it, or
indefinitely when that rule cannot be read. The nightly run records the key
on its ledger row (migration 0489, database_backup_runs.active_key_id). The
encryption view and the kit list the dumps per key, in every locale, and the
rotation and backup runbooks say so.

prisma/migrations/0489_database_backup_run_key/migration.sql

@@ -0,0 +1,18 @@
+-- The nightly database dump records the application key its rows were
+-- written under (the manifest's active key id). A dump is restored only with
+-- that key, so the recovery kit and "keys the backups still need" list it for
+-- as long as the off-host copy of the dump may still be in the bucket.
+--
+-- Nullable, no default, no backfill: a run recorded before this column reads
+-- as "key not recorded", and its dump ages out of the bucket like any other.
+-- Reversibility: dropping the column restores the previous schema.
+--
+-- @retry-on-lock-timeout
+
+DO $migration$
+BEGIN
+    PERFORM set_config('lock_timeout', '5s', true);
+    ALTER TABLE "database_backup_runs"
+        ADD COLUMN IF NOT EXISTS "active_key_id" TEXT;
+END
+$migration$;

prisma/schema.prisma

@@ -6032,6 +6032,11 @@ model DatabaseBackupRun {
   offhostResult String    @map("offhost_result")
   /// Why the run failed or was skipped, trimmed. Never key material.
   error         String?
+  /// The application key id the dump's rows were written under (its
+  /// manifest's active key). A restore refuses without it. Reader:
+  /// `readBackupKeyNeeds`, which keeps the key in the recovery kit while the
+  /// off-host copy of this dump may still be in the bucket.
+  activeKeyId   String?   @map("active_key_id")
 
   @@index([startedAt])
   @@map("database_backup_runs")