`Core.init` initialised `submitter_free_mask` with `(1 << n) - 1`, which is UB on `u64` when `n == 64` — the documented maximum that `Config.normalized` produces from the clamp. Behaviour by mode: * Debug / ReleaseSafe: panic at pool.zig:751 with "shift amount 64 is too large for operand type u64". * ReleaseFast / ReleaseSmall: x86-64 SHL masks the count to its low 6 bits, so `1 << 64 == 1` and the mask init becomes `0` — every `registerSubmitter` returns `error.NoSubmitterSlots` despite all 64 slots being allocated. Silent functional break of the API contract. Special-case the full-bitmap value to `std.math.maxInt(u64)`. Pair with a defense-in-depth `Config.validate` check that rejects `max_submitter_queues > 64` with `error.SubmitterCapExceedsBitmap`, mirroring the existing `OverflowCapExceedsBitmap` pattern. `normalized()` still clamps at 64, so the public init path is unchanged for callers that pass arbitrary large values. Regression tests in tests/integration/submitter_lifecycle.zig cover: the 64-slot success path (claims 64 distinct slots, 65th returns NoSubmitterSlots), the 1-slot boundary (smallest non-zero clamp output), and the validate() rejection for >64. Verified green under Debug, ReleaseSafe, ReleaseFast, and ReleaseSmall. Bump 0.2.0 → 0.2.1 (bugfix, no API change beyond the new error tag). Full bug analysis in docs/BUG_2026-04-25_submitter_free_mask_shift_ub.md. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>