Fix PCM buffer thread safety with proper mutex

[struktured]

Summary

The PCM circular input buffer is written by the audio thread (via projectm_pcm_add_*) and read by the render thread (via RenderFrame → UpdateFrameAudioData → CopyNewWaveformData). The previous design used std::atomic<size_t> m_start alone to coordinate, but this is insufficient — the buffer contents themselves are not atomic, so concurrent reads/writes are a data race in C++ and have been observed to cause audio corruption and crashes under sustained load.

This adds a std::mutex to protect the input buffer, locked in AddToBuffer (audio write path) and around CopyNewWaveformData in UpdateFrameAudioData (render read path). The lock is released before the heavier spectrum/FFT work, so the audio thread is only blocked for the duration of a sample copy (microseconds).

Changes

• 2 files: src/libprojectM/Audio/PCM.{cpp,hpp} (+13, -5)
• Add std::mutex m_pcmMutex to PCM
• Lock in AddToBuffer and around CopyNewWaveformData reads
• Drop std::atomic<size_t> m_start (now protected by the mutex) and remove unused <atomic> include

Design notes

A lock-free SPSC design was considered but rejected for this use case:

• The reader copies the entire ring buffer each frame (not a trailing window), so simple release/acquire publication still races on the float values themselves
• Per-sample std::atomic<float> would kill SIMD and roughly double memory
• A seqlock would work but is significantly more complex than the bug warrants
• The critical section here is microseconds; audio threads tolerate this fine for a visualizer (vs. pro-audio realtime contexts)

Test plan

• Clean build on Linux (GCC, RelWithDebInfo)
• Runtime test on NVIDIA RTX 3090, KDE Wayland — sustained PipeWire input, no audio corruption
• No regressions in beat detection / spectrum response

[kblaschke]

One of the low-priority, but recently more frequently reported issues to be fixed. LGTM, will merge.