* 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.
