simd(avx2): native __m256i for U32x8 and U32x16 — the ARX lane (TD-T22)

Replaces the `avx2_int_type!` scalar-storage polyfills for the two u32
lanes with real AVX2 registers, mirroring the shipped `U16x16` lowering
in the same file.

- `U32x8(pub __m256i)` — one register, 8 lanes.
- `U32x16(pub U32x8, pub U32x8)` — two halves, the same composition
  `F32x16(pub f32x8, pub f32x8)` already uses here. (NEON's four-quarter
  `[U32x4; 4]` is the same idea at a different register width, not a
  competing convention.)

Public surface is unchanged: every method and operator the macro emitted
is reimplemented with identical semantics, including the WRAPPING
`reduce_sum` and wrapping Add/Sub. Type names and lowercase aliases are
untouched, so both `simd.rs` dispatch arms and the `simd_avx512.rs`
re-export pick these up with no edits.

`rotate_left` is `n % 32` then `sll(n) | srl(32 - n)`. No branch for
n = 0: the ISA defines a shift count >= 32 as yielding zero, so
`sll(0) | srl(32)` is the identity. Rotate amounts in ARX ciphers are
public constants, so a runtime `n` carries no timing concern.

Why this lane: `U32x16` Add/BitXor/rotate_left is the ChaCha20/BLAKE ARX
triple that `vendor/chacha20` rides. It was already native on AVX-512
(VPROLVD), NEON, and wasm — AVX2 was the last tier still doing it in
scalar Rust, which is the default tier for CI and for any x86 build
without an explicit v4 config.

Also trampolines `U16x16::to_f32x8_{lo,hi}` to return `crate::simd::F32x8`
instead of `crate::simd_avx512::F32x8` — a public signature in the v3
backend must not name another backend's module.

Tests: 16 new, each against an inline scalar reference, with inputs
chosen so a wrong implementation fails — distinct per-lane values
(catches lane-order bugs), operands that overflow and underflow u32,
products exceeding 32 bits, rotate amounts including 0/31/32/33 (proves
the mod-32 wrap), a reduce_sum that wraps, and a U32x16 half-seam case
where lanes 7 and 8 differ (catches a lo/hi swap).

Author: claude