Store encryption keys in pw backup instead of old password

# Problem
It has been pointed out in the audit that we should not store the passwords themselves as they may leak sensitive information. (E.g., they may be used somewhere else, or they may follow a certain pattern that could expose future password choices.)

(Note that we do not store the passwords in plaintext, but in the SRP backup store that is encrypted under the user's encryption key. Nevertheless, if the encryption key is leaked these passwords can leak sensitive information beyond what is leaked by just the encryption key, as described above.)

# Possible resolutions
Several options come to mind:
1) Store password hash instead of password.
2) Store derived vault key.
3) Derive vault key from backup encryption key.
4) Accept the risk and keep as is.

# Discussion
## Discussion of resolution 1
Low effort, requires changing how vault key derivation works. First derive Hash(pw), and the derive key from there.

Medium friction, change in vault key derivation means we need to migrate existing devices.

Low protection, as password can be brute forced from password hash, if password entropy is low.

## Discussion of resolution 2
Medium effort, because encryption is usually different across devices. Key derivation depends on salt and device type. For this to work, salt must be synced across devices and derived keys must be stored for all device types.

Medium friction, because key derivation does not change substantially. However, the encryption interface must be changed to accept an optional salt.

Medium protection, as it is much harder to brute force password from derived key than from hash.

## Discussion of resolution 3
Medium effort, because need to change onboarding to obtain vault encryption key from toprf backup sdk. Then encrypt vault key under password.

Medium friction, because vault key is now derived from toprf key, and indirectly encrypted under locally derived key.

High protection, because vault key now does not leak anything about password.

## Discussion of resolution 4
Alternatively, we can accept the risk and keep things as they are. Obviously, this option is no effort and no friction, but also no added protection.

Start by reviewing the current password, vault-key, and SRP backup flow, including onboarding and the encryption interface mentioned in the issue. Compare the four proposed resolutions and identify migration and cross-device implications. This is done only once a resolution is selected and the corresponding backup and key-derivation behavior is implemented and verified.

Written by the indexing model from the issue text.