FFT: add interleaved F32/C32 APIs

[shinaoka]

Summary

• add public interleaved C32 CFFT, RFFT, and IRFFT APIs with typed FftError validation
• keep global complex storage interleaved as [re0, im0, re1, im1, ...] while retaining split shared-memory, four-step, and packed-real scratch internally
• support small and device-selected four-step/large paths, virtual padding, None / ByN / Ortho normalization, caller-owned launches, and allocating convenience APIs
• add split/interleaved benchmark strategies plus separate CFFT benchmark coverage at 4096 and 8192
• document ABI/layout, output uniqueness, device limits, and the deferred F64/C64 work

Behavior and safety

Public interleaved entry points return Result<_, FftError>. They validate dtype, shape, axis, sizes, offsets, writable layout, and input/output aliasing before the first launch or scratch allocation. Normalization is fused into terminal stores. There is no standalone interleaved conversion or scaling kernel; large real transforms retain their packed-real algorithm stages.

The existing split APIs and their normalization behavior are unchanged.

Verification

Run locally on an Apple host:

• cargo fmt --all -- --check
• cargo clippy -p cubek-fft --all-targets --features heavy,benchmarks -- -D warnings
• cargo test -p cubek-fft — 2 unit + 47 integration passed
• cargo test -p cubek-fft --features heavy — 2 unit + 77 integration passed
• cargo test -p cubek-fft --features benchmarks --test lib bench_catalog -- --nocapture — 11 passed
• cargo test -p cubek-fft --features cubecl/wgpu — 2 unit + 47 integration passed
• cargo test -p cubek-fft --features benchmarks — 8 unit + 58 integration passed
• cargo check -p benchmarks --benches
• git diff --check origin/main...HEAD

The WGPU suite passed on macOS; the test harness did not print an explicit Metal adapter identifier.

Follow-up

F64/C64 remains a follow-up because Metal does not provide native F64 execution.

Refs #6