Add FFT (spectral transform) on Vulkan compute #1

Motivation

The L1 array layer (element-wise arithmetic + sum) is in place, but the headline
use case — spectral analysis on the edge — needs an FFT.

Concretely: streaming a live vibration/audio spectrum from a Raspberry Pi 5 to a Rails
"control plane" (a Kaigi on Rails demo) currently has to fall back to a GPU-synthesised
spectrum, because there is no FFT yet. Adding FFT turns the same pipeline into a real
spectral analyzer.

Current state

GPU kernels today (shader/): add / adds / sub / mul / div / scale / sum
— element-wise arithmetic + a sum reduction. There is no fft method or shader.

Proposal

Add an FFT on Vulkan compute, exposed as a Ruby method, following the existing
shader + method pattern (*.comp → *.spv + mrb_define_method in src/gpu_narray.c):

• API sketch
  • GPU::SFloat#rfft → complex spectrum for real input (length n power of two)
  • #power_spectrum / #magnitude → GPU::SFloat of length n/2 (ready to quantise/plot)
• Backend options
  1. Hand-written radix-2 Cooley–Tukey compute shader (GLSL) — fits the current
     architecture, ~150 LoC, high learning/demo value.
  2. Integrate VkFFT — production-grade Vulkan FFT
     (larger C++ integration).

Data already lives in a VkBuffer; the transform should run in-place on the GPU and
only copy back via #to_a. This is the natural L2 (DSP) layer.

Acceptance criteria

• n-point (power-of-two) real→complex FFT as a Vulkan compute dispatch
• magnitude / power-spectrum helper returning a GPU::SFloat
• examples/fft_spectrum.rb — FFT of a known multi-tone signal, peaks at expected bins
• a test in test/
• runs on Pi 5 (V3D) and on desktop

Context

Toward 名古屋Ruby会議05 (2026-09-19): "the code you prototype with is the code you
deploy to the edge." An FFT is the first DSP primitive that makes that story concrete.