docs: remove stale gpudemod readme

internal/demod/gpudemod/README.md

@@ -1,34 +0,0 @@
-# gpudemod
-
-Phase 1 CUDA demod scaffolding.
-
-## Current state
-
-- Standard Go builds use `gpudemod_stub.go` (`!cufft`).
-- `cufft` builds allocate GPU buffers and cross the CGO/CUDA launch boundary.
-- If CUDA launch wrappers are not backed by compiled kernels yet, the code falls back to CPU DSP.
-- The shifted IQ path is already wired so a successful GPU freq-shift result can be copied back and reused immediately.
-- Build orchestration should now be considered OS-specific; see `docs/build-cuda.md`.
-
-## First real kernel
-
-`kernels.cu` contains the first candidate implementation:
-- `gpud_freq_shift_kernel`
-
-This is **not compiled automatically yet** in the current environment because the machine currently lacks a CUDA compiler toolchain in PATH (`nvcc` not found).
-
-## Next machine-side step
-
-On a CUDA-capable dev machine with toolchain installed:
-
-1. Compile `kernels.cu` into an object file and archive it into a linkable library
-   - helper script: `tools/build-gpudemod-kernel.ps1`
-2. On Jan's Windows machine, the working kernel-build path currently relies on `nvcc` + MSVC `cl.exe` in PATH
-3. Link `gpudemod_kernels.lib` into the `cufft` build
-3. Replace `gpud_launch_freq_shift(...)` stub body with the real kernel launch
-4. Validate copied-back shifted IQ against `dsp.FreqShift`
-5. Only then move the next stage (FM discriminator) onto the GPU
-
-## Why this is still useful
-
-The runtime/buffer/recorder/fallback structure is already in place, so once kernel compilation is available, real acceleration can be inserted without another architecture rewrite.