Security: keep enrolled LUKS2 tokens from passing LUKS key checks

[maralcbr]

cryptsetup open --test-passphrase tries every enrolled LUKS2 token that needs no PIN (TPM2, FIDO2, keyring) before the key it was given. If the token unlocks, it reports success and the token's slot, whatever key was passed. The key checks merged in #517, #532 and #527 relied on it:

• first-boot owner provisioning (install/provisioning/luks-rekey.sh, which the Apple path also uses through dispatch since Apple owner provisioning through lifecycle dispatch entrypoints #545)
• factory reset's check of the current disk passphrase
• omarchy-drive-password's current-password and new-key checks

So a token left by a previous owner or seller passed for any password. Setup could record the token's slot as the owner's and never add the owner's password. Slot listings also parsed luksDump with a pattern that matches luks2-keyring token lines, so token ids were counted as keyslots, including in omarchy-apple-silicon-boot-check.

What changed:

• Every key check passes --token-type passphrase-only, a type no token has, so only the key decides.
• Slot listings read only the Keyslots: section. For factory reset's throwaway-slot lookup this is hardening only: the old parse still found the right slot there.

On cryptsetup 2.8.8, --disable-external-tokens alone doesn't help (the keyring token is built in), and --key-slot N still lets a token bound to slot N answer. Mutating verbs (luksAddKey, luksKillSlot, luksChangeKey) don't consult tokens.

The same fix for the upstream-ready branches is on upstream/47-luks-rekey-journal and upstream/47-drive-password-sync in the fork. The branch merges quattro-upstream after #545. The omarchy-provision-owner hunk was dropped because #545 removed rekey_luks_apple, and the Apple token tests were ported to #545's dispatch harness.

Testing

• New real-cryptsetup runs in luks-rekey-journal-test.sh (full first-boot provisioning) and drive-password-test.sh. Each uses a file-backed LUKS2 volume with an imported systemd-tpm2 token and a live luks2-keyring token, whose key is in the session keyring. Each run first shows that a bare open with a wrong key reports the token's slot, then checks that setup and the password change accept only real keys. Where the kernel keyring is out of reach (no keyctl, or Docker's default seccomp profile) they print a skip line.
• Fake-token cases cover the journal, drive password, factory reset and the boot check, which gets a luksDump with TPM2 and keyring token lines. On the Apple dispatch path, they cover:
  • the owner and recovery slots beside a token
  • a retry beside a token
  • a keyring token numbered like a missing recovery slot
• Each production change was reverted one at a time. The new tests catch every one except the factory-reset slot listing, where the old parse was not wrong.
• ./test/all as a non-root user in an arm64 Arch container (cryptsetup 2.8.8), with Docker's default seccomp profile and with seccomp unconfined, plus packages/omarchy-mac/boot/test/all (119 ok), after the merge. The only failures are the same 5 that base fails (no omarchy-pkgs checkout, Plymouth publish, and the flaky system-sleep-ownership-migration-test.sh).
• Not run: hardware, or a real TPM2 or FIDO2 token.

Second review: no problems found in the production code. It confirmed the cryptsetup behaviour and that no token-blind key check is left. Test gaps it raised in the mx-mac port are fixed there. A later review rated the rebase onto #545 safe.