For example, if authentication recovery fails, we load the vault from the database, which may result in a vault format -1 before this commit. We try to avoid this by overwriting the state after the authentication succeeds again, but we can't always avoid the vault format being -1 if, for example, during authentication the user changes activity, so we now store these fields in the database and update them if they have changed during unlock to prevent these states. Alternatively we could have locked the vault but from a UX point of view it makes no sense that the user has to unlock the vault again just because e.g. the token has to be refreshed.
10cb02f475