fix(backup): pin verified hook failure release

Pin the CI-built resticontainer image that rejects failed pre-backup hooks. Record the approved SQL-backed directory deployment gates in the replication RFC.

Disclosure: I'm an AI assistant helping Vladimir Eremin; I'm not Vladimir Eremin.

docs/rfcs/composition-replication.md

@@ -123,7 +123,11 @@ The candidate SSO arrangement has two Authelia/nginx deployments and replicated
 
 The Galera arbitrator provides voting without another SQL data copy. The remaining data member and arbitrator can preserve quorum after one data location fails. WAN latency and stable connectivity must be checked before choosing this topology. [MariaDB deployment variants](https://mariadb.com/docs/galera-cluster/galera-architecture/galera-cluster-deployment-variants/)
 
-The existing users source is a manually maintained YAML file. Identical read-only distribution is a possible experiment, but Authelia does not officially endorse that workaround for HA. Production acceptance requires either an explicitly accepted limitation or a supported user-directory design with its own failure coverage. Migrating passwords must preserve usable credentials or have an approved reset procedure; changing the backend is not assumed to convert hashes automatically. [Authelia stateful dependencies](https://www.authelia.com/overview/authorization/statelessness/)
+The existing users source is a manually maintained YAML file. The selected replacement is LLDAP backed by the replicated MariaDB group, with a local LLDAP instance at each SSO location. Authelia supports this directory implementation. Existing account identifiers, profile attributes and application groups must survive migration. LLDAP cannot import the existing YAML password hash; the operator has accepted one password enrollment through a private setup page. Keep the old SSO authoritative until enrollment and migration checks pass. [Authelia LLDAP integration](https://www.authelia.com/integration/ldap/lldap/)
+
+The initial placement uses a separate `identity` composition at `198.18.16.150` on Daedalus, `198.18.18.150` on Metis and `198.18.17.150` on Icarus. Daedalus and Metis own SQL data and directory instances; Icarus owns the Galera arbitrator. Each location also owns a Valkey data member and Sentinel voter. The existing SSO frontend addresses remain separate. These are explicit allocations for this deployment, not reserved addresses or mandatory topology for other APEX applications.
+
+Stage the new backend beside the existing SSO database. Use an explicit one-time SQL bootstrap, normal native joins thereafter, and a consistent logical export for migration. Ordinary container restart must never repeat cluster bootstrap or replay an old session snapshot. A direct private Daedalus–Metis transport is required so that Icarus loss does not also remove connectivity between the surviving data members. Password enrollment, verified replication transport and local dependency readiness are deployment gates, not consequences of starting containers.
 
 Valkey replication is asynchronous and can lose acknowledged recent changes. The proposed SSO pattern therefore cannot claim seamless preservation of every session or revocation. Its production profile must state and test the resulting security and user-visible behavior. A requirement for lossless session state requires a different validated arrangement, not a stronger label on Sentinel.