Walsh-Hadamard as a plain butterfly on both paths, no FFTW plans (closes #89)

[sadit]

Stacked on #88 (its base is sq/86-asymmetric-graph, which holds RandomizedHadamard, the main beneficiary); GitHub retargets it to main once #88 merges.

The problem (#89): transform!(hp::HadamardProjection, out, v) went through Hadamard.fwht_natural!, which builds an FFTW plan under FFTW's global planning lock on every call. Per vector that is 170–400 µs at 128–4096 dimensions, and worse with threads, which serialize on the lock; the matrix path's one batched plan (#54) still executed at 1.5–12 µs per column. A plan cached per structure removes the plan and the lock but FFTW's execution of this shape (a 2×2×…×2 r2r) stays at 3–54 µs, MEASURE included.

The change: Projections.fwht!, the iterative in-place butterfly, log2(n) passes of sums and differences and a scale by 1/n, natural (Hadamard) ordering: bit for bit what fwht_natural! produced, so every encoding built on the projection is unchanged. Both transform! paths use it; the matrix path runs one per column under @BATCHES, with the copy from X inside the batches (a serial copyto! ahead of the loop cost three times the transform). Hadamard.jl leaves Project.toml.

dim	per vector, one thread	RandomizedHadamard rotation	per column, 100k columns, 64 threads
128	493 ns (was 167 µs)	565 ns	41 ns (was 1.5 µs)
512	1.9 µs (was 241 µs)	3.1 µs	123 ns (was 5.8 µs)
1024	3.7 µs (was 284 µs)	6.1 µs	232 ns (was 11.9 µs)
4096	15 µs (was 399 µs)	24 µs	—

The Hadamard rotation is now cheaper than the QR one (~40 µs at 384/512-d), as its flops say.

Tests: the butterfly against the Sylvester matrix H/n at 1–1024 dimensions in Float32 and Float64, fwht!(fwht!(u)) == u/n, the matrix path equal to the per-column one for any batch size. Full Pkg.test() gate green on Julia 1.12 with Aqua. Headroom noted on the issue: the first three passes have inner loops too short to vectorize.

🤖 Generated with Claude Code