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.

migrations/postgresql/2026-11-02-120000_reset_user_key_id/up.sql

@@ -0,0 +1,4 @@
+-- Key rotations before this kept the id of the old user key, so every new
+-- cipher was refused from then on. Stale ids can't be told apart, so clear
+-- all of them; clients record their current key's id again when it's empty.
+UPDATE users SET key_id = NULL;

migrations/postgresql/2026-11-04-120000_add_v2_upgrade_token/down.sql

@@ -0,0 +1,2 @@
+ALTER TABLE users DROP COLUMN v2_upgrade_token;
+ALTER TABLE users_organizations DROP COLUMN v2_upgrade_token;

migrations/postgresql/2026-11-04-120000_add_v2_upgrade_token/up.sql

@@ -0,0 +1,2 @@
+ALTER TABLE users ADD COLUMN v2_upgrade_token TEXT;
+ALTER TABLE users_organizations ADD COLUMN v2_upgrade_token TEXT;