Security: keep enrolled LUKS2 tokens from passing LUKS key checks

[maralcbr]

Security fix for the frozen branch. It is the same fix as omacom#549.

cryptsetup open --test-passphrase tries every enrolled LUKS2 token that needs no PIN (TPM2, FIDO2, keyring) before the key it was given, and reports the token's slot whatever that key was. Here it decided which slot a password opens and whether it opens the disk:

• luks_slot_for in omarchy-provision-owner
• the Apple re-key's final owner and recovery checks
• the staged-key check before the generic re-key
• factory reset's current-passphrase check
• omarchy-drive-password (including Change the root LUKS key before syncing login and root passwords #272's checks)

A token a previous owner left behind therefore passed for any password. Provisioning could record the token's slot as the owner's, and the generic re-key could keep only that slot and kill the owner's new one. Slot listings also counted luks2-keyring token lines as keyslots, including in omarchy-apple-silicon-boot-check.

Key checks now pass --token-type passphrase-only (a type no token has), or compare the slot a key opens with the slot it should hold. Slot listings read only the Keyslots: section. luks_slot_for now also runs cryptsetup under LC_ALL=C, since it parses cryptsetup's English output.

Testing

• drive-password-test.sh runs against a real file-backed LUKS2 volume with an imported systemd-tpm2 token and a live luks2-keyring token, whose key is in the session keyring. The test first shows that a bare open with a wrong key reports the token's slot. It skips where the kernel keyring is out of reach.
• Fake-token cases cover provisioning (owner slot, a resumed run with a wrong password, a wrong recovery key, and a token numbered like a missing recorded slot), factory reset and the boot check's luksDump parse.
• Each production change was reverted one at a time, and a test fails for each one. The one exception is 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, seccomp unconfined so the live token runs): the only failures are the same 4 environment failures as origin/main (no omarchy-pkgs checkout, Plymouth publish). The targeted files were rerun after the last test additions.
• Not run: hardware, or a real TPM2 or FIDO2 token.

Second review: no problems found in the production code. The two missing tests it raised (the slot listing in omarchy-provision-owner, and the resumed-run owner check) were added. Fable re-check owed.