fix: harden backup and restore compatibility

[RentnerKev]

Summary

Harden backup and restore compatibility for the v1.0.0-alpha.6 baseline and the final Beta 1
state.

Backup contract

The current appliance backup must cover all persisted state required to reconstruct the product:

• PostgreSQL data
• controller state
• application encryption key
• certificates and private material
• certificate candidates
• ACME accounts
• durable certificate operations/events and retry state
• DNS provider credentials
• host/certificate binding jobs
• users, roles, permissions, and relevant authentication state
• Access Policies, Basic Auth accounts, Proxy Hosts, and Redirect Hosts
• trusted CAs
• desired runtime/revision state
• managed CrowdSec state under /var/lib/rentnerproxy/crowdsec, including the detection database
  and credentials that must survive restore; explicitly identify any safely regenerable subsets
• encrypted External CrowdSec configuration and bouncer credential in PostgreSQL (the external
  Local API itself remains operator-owned)
• shipped Forward Auth/importer persisted state where applicable

Redis, proxy request logs, and deployment environment variables remain outside the backup if that
is still the verified architecture contract. Required deployment configuration, including
trusted-proxy CIDRs and canonical management origin, must be preserved alongside the backup and
called out during restore validation. CrowdSec transient sockets, caches, and access logs should
be excluded only when regeneration has been verified.

Compatibility contract

• current Beta backup -> current Beta restore is mandatory
• alpha.6 backup/state -> Beta restore/upgrade is mandatory
• Alpha 4 and Alpha 5 compatibility follows the direct-support decision in fix: harden alpha-to-beta upgrade path #67/test: add release upgrade compatibility matrix #68
• older formats/releases are supported only when explicitly listed and proven
• synthetic v1/v2 format fixtures may test parsers but do not replace real release/image
  compatibility evidence
• incompatible/unsupported formats fail clearly and are never silently reinterpreted

Verify

• manifest/version/digest validation before destructive restore
• database, controller, certificate, encryption, policy, integration, and desired-state recovery
• managed CrowdSec detection state, local API registration, bouncer credential regeneration or
  recovery, ownership, and permissions after restore without exposing the Local API publicly
• ownership and restrictive permissions for restored secret material
• interruption, corrupt/missing archive, wrong encryption key, incompatible version, and partial
  extraction behavior
• revision-confirmed runtime reconciliation after restore
• representative HTTP/HTTPS, certificate, authentication, and policy behavior
• rollback into fresh volumes with the previous exact image; never run an older image against an
  upgraded database

Acceptance criteria

• Current -> current backup/restore passes with all final Beta state.
• Alpha 6 -> Beta path passes with real release artifacts/state.
• Supported older formats/releases are explicitly listed and evidence-backed.
• Unsupported and corrupt input fails before unsafe replacement or silent data loss.
• Secrets are neither logged nor returned and restore permissions are correct.
• Managed CrowdSec persists required state and safely regenerates only documented disposable state.
• Interruption and recovery behavior is automated and deterministic.
• Production smoke and release gate cover the current supported path.
• Deployment environment exclusions and operator responsibilities are documented.

Priority and sequencing

P0. Coordinates the supported upgrade matrix in #67/#68 and the security review in #72. Must be
complete before #75 closes.