fix: a master password is held to its minimum at every door

[blaipr]

Every account secret is sealed with the master password, so its minimum length is the floor under the whole vault. Only the installer enforced it, and it measured in bytes:

• Installer refused under 11, but counted with strlen(), so five CJK characters (15 bytes) passed a rule that says "at least 11 characters".
• The web's encryption settings accepted any non-empty new master password. That covers both the full rotation and the "hash only" option.
• sp:updateMasterPassword accepted any non-empty value too.

So an installation could be re-keyed to a the day after it was set up.

Change

• New MasterPass::MIN_LENGTH (11) and MasterPass::assertLongEnough(), measured with mb_strlen(). It is asked by:
  • the installer, replacing its own check
  • MasterPass::changeMasterPassword(), which the web rotation and the CLI both reach, before anything is re-encrypted
  • the web configEncryption/save action, after the same/repeat checks, because its "hash only" option replaces the stored hash without going through the rotation
• Existing installations are unaffected until they change their master password.

Tests

• Unit: the minimum is counted in characters (eleven ASCII pass; five CJK characters are refused), and the rotation refuses a short password before re-encrypting anything.
• Integration: the web refuses a short new password, both for the rotation and for the hash-only option.
• Existing MasterPassTest cases used 456 and new as new master passwords; they now use realistic ones.

All four new tests fail without the fix.