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.

docs/ops/backup-restore.md

@@ -146,8 +146,10 @@ once the lifecycle rule has expired every object written under it.
 A copy carries the database's ciphertext as stored, so it needs the
 application keys it was written under, also after a rotation. Keep a retired
 `ENCRYPTION_KEYS` entry until no copy you may still restore needs it. **Admin →
-Encryption → Keys the backups still need** lists them. Off-host objects also
-need `BACKUP_ENCRYPTION_KEY` (or the previous key that wrote them).
+Encryption → Keys the backups still need** lists them, the database dumps
+included: a dump needs the key that was active when it was taken, for as long
+as it is kept on this server or in the bucket. Off-host objects also need
+`BACKUP_ENCRYPTION_KEY` (or the previous key that wrote them).
 
 ## Size and memory
 

docs/ops/encryption-key-rotation.md

@@ -137,10 +137,15 @@ under `v1` (the synthetic id assigned to the existing `ENCRYPTION_KEY`).
 > So before step 4, also check **Admin → Encryption → Keys the backups still
 > need**. It lists, per key id, the stored copies that need it with the oldest
 > date, and when the last off-host copy needing it expires under the bucket's
-> lifecycle rule. Keep the old key in `ENCRYPTION_KEYS` until it is no longer
-> listed there (the weekly copy replaces itself within a week; delete old
-> uploaded copies you no longer want, and wait out the off-host retention), or
-> accept that those copies cannot be restored. Copies written before v1.39.3
+> lifecycle rule. The database dumps are listed too: a dump is restored only
+> with the key that was active when it was taken (`db-restore` refuses
+> without it), so the old key stays listed while a nightly or pre-migration
+> dump taken under it is on this server, and until the bucket's rule for
+> `database/` has expired the off-host copies. Keep the old key in
+> `ENCRYPTION_KEYS` until it is no longer listed there (the weekly copy
+> replaces itself within a week; delete old uploaded copies you no longer
+> want, and wait out the dump and off-host retention), or accept that those
+> copies cannot be restored. Copies written before v1.39.3
 > did not record their keys and are listed as such: treat them as needing
 > every key that existed when they were written.
 >