Implement V2 key rotation support (#7766)

* Implement V2 key rotation support

* Clear user key ids left stale by key rotations

* Refuse key ids that aren't 32 lowercase hex characters, like upstream

* Save the signature key pair before the v2 account state

* Gate v2 logins on upstream's v2 encryption check

* Document the v2 encryption feature flags

* Remove the v2 upgrade feature flags

With force-upgrade-v2-encryption on, the clients loop on any v1 account that stays v1 on a vault route: the migration check runs fullSync(false), which writes lastSync, which triggers the scheduler again. No server response stops it, so don't serve the flag until the clients fix it.

pm-30144-sdk-key-rotation and pm-31050-no-logout-key-upgrade-rotation only serve that upgrade, so they go too.

* Move the v2 upgrade token migration to its own version

Diesel identifies a migration by the date in its folder name alone, and silently drops one of two folders that share it. The Custom Roles migration uses the same date.

* Refuse rotations from a replaced user key, like upstream

Both rotation endpoints accept the optional oldUserKeyId. When it and the
stored key id are both set and differ, the rotation is refused with a 409
asking the client to sync, before the account keys are checked or anything
is written.

Also correct the comment on saving the signature key pair first: by then the
vault data is already re-encrypted, so a failure there doesn't keep the
account usable.

* Update the v2 client minimum in .env.template and the key pair comments

V2 accounts need 2026.10.1, or 2026.10.2 for the desktop app, so the per-flag versions are only enough to create one. The comments on saving the signature key pair now cover the rotation of an account that is already v2.

src/api/push.rs

@@ -12,7 +12,7 @@ use tokio::sync::RwLock;
 
 use crate::{
     CONFIG,
-    api::{ApiResult, EmptyResult, UpdateType},
+    api::{ApiResult, EmptyResult, LogOutReason, UpdateType},
     db::{
         DbConn,
         models::{AuthRequestId, Cipher, Device, Folder, PushId, Send, User, UserId},
@@ -192,15 +192,15 @@ pub async fn push_cipher_update(ut: UpdateType, cipher: &Cipher, device: &Device
     }
 }
 
-pub async fn push_logout(user: &User, acting_device: Option<&Device>, conn: &DbConn) {
+pub async fn push_logout(user: &User, acting_device: Option<&Device>, reason: Option<LogOutReason>, conn: &DbConn) {
     if Device::check_user_has_push_device(&user.uuid, conn).await {
-        push_logout_to_relay(user, acting_device);
+        push_logout_to_relay(user, acting_device, reason);
     }
 }
 
 // Sends the logout without checking for push devices first.
 // Needed after deleting a user, when the devices are already gone from the database.
-pub fn push_logout_to_relay(user: &User, acting_device: Option<&Device>) {
+pub fn push_logout_to_relay(user: &User, acting_device: Option<&Device>, reason: Option<LogOutReason>) {
     tokio::task::spawn(send_to_push_relay(json!({
         "userId": user.uuid,
         "organizationId": (),
@@ -209,7 +209,8 @@ pub fn push_logout_to_relay(user: &User, acting_device: Option<&Device>) {
         "type": UpdateType::LogOut as i32,
         "payload": {
             "userId": user.uuid,
-            "date": format_date(&user.updated_at)
+            "date": format_date(&user.updated_at),
+            "reason": reason.map(|r| r as i32),
         },
         "clientType": null,
         "installationId": null