fix(permutation): make bitwise_permute constant-time

[coderdan]

Stacked on #164 — review/merge that one first.

Summary

• bitwise_permute previously used BitArray::get_unchecked(secret_index) to fetch bits at key-derived positions. The bit array fits in a single cache line (≤16 bytes) so it's not exploitable by classic cache-line probing, but it's still a microarchitectural hazard — port pressure, store-buffer effects, and other intra-cache-line side channels can leak secret indices on some CPUs.
• Reimplemented as: unpack input to one byte per bit (MSB-first) → permute through the constant-time permute_array primitive → repack to bytes. This routes the bit-level operation through the same scan-and-mask machinery introduced in fix(permutation): close cache-timing side-channel in permute_array #164.
• Secret intermediates (bytes, bits, permuted) wrapped in Zeroizing<_> for unwind safety, matching the elementwise pattern.
• Drops direct bitvec usage in bitwise.rs; the BitArray machinery is no longer needed there.

Performance impact

Apple silicon (arm64), --release, 500K iterations, key bytes pre-extracted via the public Permute API for the "old" reference:

N	old (variable-time)	new (constant-time)	overhead
8	1.9 ns	53.9 ns	28×
16	5.7 ns	267 ns	47×
32	34 ns	1.45 µs	42×
64	80 ns	5.6 µs	70×
128	137 ns	27.3 µs	199×

In line with the elementwise overhead — bit-level bitwise_permute reuses permute_array internally, so the cost profile matches. Same SIMD-shuffle follow-up (tbl/pshufb) applies if these sizes show up in a hot path.

Verification

• cargo test -p vitaminc-permutation — 6 unit + 3 doctests pass (round-trip, key inversion, bitwise correctness across u8/u16/u32/u64/u128 + NonZero variants)
• cargo fmt --check — clean
• ct_analyzer on release asm (arm64 + x86_64) — PASSED, 0 errors / 0 warnings
• Constant-time scan-via-permute_array, no secret-indexed loads remain in bitwise.rs

Test plan

• Existing bitwise_permute_case exercises N=8/16/32/64/128 across all int and NonZero variants
• CI green

[tobyhede]

LGTM.
Adding some unit tests would improve, but not a deal breaker