Fix data race in AudioProcessor: thread-safe audioSamples and audioEnergy

[shawnzhu]

Summary

• Add NSLock to protect audioSamples and audioEnergy from concurrent access
• These properties are written from the audio tap callback thread (in processBuffer) and read from arbitrary threads (e.g., main thread polling relativeEnergy for VAD)
• Lock is held only for the minimum critical section — energy calculation and callback invocation happen outside the lock

Problem

audioSamples and audioEnergy are plain var properties with no synchronization, causing data races when:

1. The audio tap callback writes via processBuffer()
2. Other threads read via relativeEnergy, audioSamples, or purgeAudioSamples()

This manifests as stale/inconsistent values when polling relativeEnergy from the main thread for voice activity detection, and can potentially crash in optimized builds.

Test plan

• All 194 existing unit tests pass
• swift build succeeds
• Manual test: poll relativeEnergy from main thread during recording — values should update consistently

Fixes #442

🤖 Generated with Claude Code

[shawnzhu]

human here: manually tested and it works for me.

The use case is using Whisper's audio energy to detect speech pause.

[shawnzhu]

@ZachNagengast would you be able to review this? You have the most context on the AudioProcessor code. Happy to address any feedback.

[ZachNagengast]

@shawnzhu Thanks for the contribution, my main thought currently is that this is handled in #412, in somewhat of a different way. Would you be able to test out that PR with your implementation and see if it covers what you were aiming for with this? If not, we'll have to reconcile them.