init/luks: dispatch PIN-bearing tokens serially in token-ID order

[pilotstew]

Two PIN-bearing tokens (e.g. TPM2-PIN and FIDO2-PIN) enrolled to the same volume are already serialized by inputMutex (and fido2Mu), so prompts queue rather than overlap. The remaining issue is ordering — parallel goroutines race to grab the mutex, so the user sees prompts in non-deterministic order each boot. With more than one PIN method this is confusing: a user who enrolled TPM2 first as their preferred unlock can't tell which boot will actually prompt for it first.

Change

Classify tokens up front in luksOpen:

• PIN-bearing tokens (TPM2 with tpm2-pin, FIDO2 with fido2-clientPin-required) collect into a pinTokens slice.
• Non-PIN tokens fan out as today.

A single goroutine then walks pinTokens in slice order — already sorted by ID via the sort.Slice in luksOpen — calling recoverTokenPassword serially. A skipped/failed token advances to the next; a successful unlock closes done and stops the loop.

The done check before each PIN iteration also lets a parallel non-PIN unlock cancel the loop without waiting on the next prompt to time out.

New predicate

tokenNeedsPin(t luks.Token) bool parses the token payload JSON to determine dispatch group. Returns false for malformed payloads, missing fields, and unrelated token types so behaviour falls through to today's parallel path on any classification doubt.

Tests

init/token_orchestration_test.go:

• TestTokenNeedsPin — table-driven JSON classification across both types
• PIN-loop ordering, short-circuit on success, parallelism with non-PIN, cancellation on non-PIN success, skip-advances-loop, sort determinism
• A negative-form contract test that documents runPinTokens does NOT sort — sorting is luksOpen's responsibility

The production loop is mirrored by runPinTokens so it can be exercised without real LUKS devices, swtpm, or hardware tokens.

[anatol]

Thank you!