fix(backups): say how an archive is protected instead of assuming an envelope

[NathaelB]

Part of #177. Found while writing #182, and worth landing before it.

The defect

#190 and #192 shipped Backup.key: KeyRef and an endpoint that requires key_provider, key_name and key_version on every archive. Both assume every archive is wrapped by a key manager.

The family of backup that actually ships is not. CloudNativePG hands the archive to the object store, which encrypts it under a key the store holds. Nothing wraps a data key for it, so there is no key reference to record.

Writing the reporting side is what surfaced it: I went looking for the value a data plane would put in key_provider for a real archive and there is none. The only field that fits is the installation's configured wrapping key, which unwraps nothing, and which a restore would read back as an instruction to go and fetch it.

The fix

docs/backup-encryption.md already makes this distinction in prose. This makes it in the type:

pub enum ArchiveProtection {
    /// The store encrypted it under a key the store holds. No key reference,
    /// because there is no key this platform could be asked for.
    StoreManaged,
    /// A data key wrapped by a key manager.
    Envelope(KeyRef),
}

A restore can now tell which one it is holding without reading anything, and needs_a_key_manager() answers the question it actually has. The variant is not a detail of how the bytes were written: it answers what a customer asks, which is whether this platform can read their archive.

Both halves of the mistake are silent, so both are refused

An envelope with no key is an archive nobody can open. A key beside a store managed archive is a key that opens nothing. Neither shows up until a restore, which is the worst possible moment, so neither is repaired or filled in:

• In the type — the variants make both unrepresentable.
• In the schema — backups_envelopes_name_their_key makes both unwritable, with a test that inserts a keyless envelope through raw SQL and asserts the database refuses it.
• At the endpoint — the three key fields go together or not at all, with a test for each of the three partial sets.

The migration

Additive and reversible. The key columns become nullable, a protection column says which mechanism was used rather than leaving it inferred from whether the others are there, and the default that backfills existing rows as envelope is dropped immediately afterwards so a new row cannot inherit a protection nobody stated.

Every row written so far was written under the old assumption, and there are none in production, so the backfill is correct by construction rather than by luck.

Verification

cargo test -p aether-postgres --test backups     9 passed, against a real Postgres
cargo clippy --workspace --all-targets           clean
cargo nextest run --workspace                    994 passed, 1 skipped

The full run had every REQUIRE_ guard armed, so nothing skipped itself.

.sqlx and openapi.json were regenerated, not edited.