User account key rotation is not atomic

• I have searched the existing Closed _AND_ Open [Issues]( _AND_ [Discussions]( • I have searched and read the [documentation]( (most of bug report form is irrelevant) POST /accounts/key-management/rotate-user-account-keys currently performs a long sequence of database operations without a DB transaction and returns early on error. This allows partial commits across account data categories which can leave account state inconsistent. The endpoint is intended as all-or-nothing key rotation operation, and partial success means some encrypted payloads/key metadata are updated while others are not. If my understanding of the code is correct, it is possible to run into an exact failure like this: 1. Have an account with at least one folder, one emergency-access entry / org recovery key, and at least one send; 2. Trigger key rotation; 3. Keep folder/emergency/recovery updates value, but set one send.deletionDate to an invalid (bear with me here) far-future value (e.g. now …