Follow-up: add NEON UDOT backend for dot_u8 once stabilized

Context

#6506 left an explicit follow-up for ARM NEON in `dot_u8`:

ARM NEON `UDOT` path would bring SIMD gains to Apple Silicon.

I prototyped a pure-Rust NEON backend using stable intrinsics (`vmull_u8` + `vpadalq_u16`), but it regresses ~2× vs the current scalar path on Apple M-series (13.4 µs → 26.3 µs at dim=1024, measured via `cargo bench -p lance-linalg --bench dot -- "Dot\\(u8"`). LLVM auto-vectorization already emits good NEON for the scalar loop on aarch64, and the widening-multiply approach can't beat it without UDOT.

The UDOT intrinsic (`vdotq_u32`) would close the gap but is still behind the unstable `stdarch_neon_dotprod` feature — see rust-lang/rust#117224.

Options when this unblocks

• Wait for `stdarch_neon_dotprod` stabilization — cleanest; tracked upstream.
• Compile a C kernel via `build.rs` with `-march=armv8.2-a+dotprod`, following the existing bf16/f16 pattern (#6510). Would work on stable today; heavier change.

Tagging for visibility.

Start with the dot_u8 benchmark command and the existing bf16/f16 build.rs pattern referenced in the issue. Compare the current scalar path with the proposed NEON UDOT options once the Rust intrinsic is available or a C kernel is chosen. Done means an ARM NEON backend is added without the regression seen in the prototype, with benchmark results confirming the change.