Require accounts to still read the same after a master password change

[blaipr]

The gap

UpdateMasterPasswordCommandTest covered what the command refuses, and that a failed rotation rolls back as one transaction (#707). What nothing asserted is the thing the operation exists for:

after a successful rotation, the accounts are still readable — and read back as the same passwords they held before.

A rotation that quietly mangled a password would have passed every test in that file. It would be found by a user, months later, with nothing to go back to. In a password manager that is the worst outcome available.

What the test establishes

1. Two accounts and a history entry stored with known, different passwords, encrypted for real under the current master password (the history row's mPassHash stamped so the rotation does not skip it).
2. Each read back and checked before the rotation — so a bad fixture cannot be mistaken for a good result.
3. The rotation runs and reports success.
4. Each read back again under the new master password and required to be the same plaintext — not merely something that decrypts.
5. The old master password no longer validates; the new one does.

One thing worth knowing

The fixture reads and writes go through SQL rather than AccountService: the service scopes its results to the signed-in user, and the CLI container never logs one in, while the rotation itself carries no such filter. Going through the service would have tested the filter, not the rotation. That is written down in the test.

Not covered

Custom fields are rotated in the same transaction and are not asserted here — the command's own output calls out accounts and history, and that is what this covers.

Testing

Integration: 14 green in the class, over two runs, no lock contamination.