Pad saved backups to fixed sizes, so a backup's size doesn't show how much the vault holds

Today: an export's encrypted payload gets a random 0.2–6 KB of padding (VaultBackupEncryptor, .random), but isn't rounded to a fixed size. A PDF prints "there are N QR codes" and "Page N of M", and each QR carries about 375 bytes of ciphertext. So a backup shows roughly how many items it holds.

The risk: after someone is given the duress password, finding a 60-code backup of the real vault next to a duress vault with 5 items shows a bigger vault exists.

Decision (Bradley, 2026-09-27): pad saved exports (PDF backups and auto-backups) up to fixed sizes.

• A 32 KiB minimum of ciphertext, about 130 typical items, or roughly 90 QR codes. Above that, the next power of two (64, 128, 256 KiB …).
• The padding has to be inside the encryption. The outer EncryptedVault JSON can be read without the password, so padding there would leave the real length readable. It goes in the payload's existing obfuscationPadding, sized so the compressed, encrypted payload lands just under the bucket. That keeps the backup format as it is, so older builds can still restore.
• Device transfer keeps today's random padding. It saves nothing, and at 2 s per QR code a padded transfer would take about 3 minutes.

Not addressed here (guidance, not code): a real-vault backup that the duress vault's backup password can't open is a bigger tell than its size. Keep real-vault backups off the phone, and give the duress vault its own auto-backup folder.

Also: update docs/on-device-encryption.md (it says exports pad "by a random amount rather than to a fixed size"), and add tests that exports of very different vaults are the same size and still restore.