diag(20.3): A/B test build for multi-peer CPU-spike regression

This is a DIAGNOSTIC build, not a shipping fix. Two suspect code paths
are neutralized so we can confirm whether they are the regression source.
Investigation tracked in .planning/debug/cpu-spikes-beta12-regression.md.

ABTEST 1 (src/core/njclient.cpp):
  Revert DecodeMediaBuffer's SpscRing<DecodeChunk, N> from 256 back to 32.
  Confirms whether the 1 MB per-buffer × N peers × per-interval heap
  allocation introduced by 0e9cbae (in beta.20.1+) is the cause of the
  audible CPU spikes that grow with peer count.
  Side effect: re-introduces the original interval-overflow cutoff bug at
  high bitrates (decbuf_drops will climb in /rcmstats).

ABTEST 2 (juce/JamWideJuceEditor.cpp):
  Stub the broadcastBeatHeartbeat() call from timerCallback.
  Confirms whether ~1.5 Hz JSON build + wsMutex_ acquisition + WebSocket
  send (introduced in beta.12 by 755257d) is the source of the baseline
  CPU bump users have reported since beta.12.
  Side effect: video companion sync indicator stops updating.

How to use:
  - A/B compare against beta.20.2 under same load (4+ peers, 30+ min)
  - Watch audible-glitch cadence, Activity Monitor CPU% baseline,
    /rcmstats decbuf_drops
  - Each ABTEST can be toggled independently for symptom attribution
    (search for "=== ABTEST" markers in source)

DO NOT ship as a normal beta. download.md still points to beta.20.2.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: mkschulze

CHANGELOG.md

@@ -9,6 +9,19 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 The 1.1 line is a complete JUCE rewrite (1.0 was CLAP/ImGui). Per-beta release notes for `1.1-beta.1` through `1.1-beta.20` are on the [GitHub Releases page](https://github.com/mkschulze/JamWide/releases) and are not duplicated here. Entries are tracked below starting with `1.1-beta.20.1`.
 
+## [1.1.0-beta.20.3] - 2026-05-04 — DIAGNOSTIC BUILD
+
+> **⚠ This is not a regular beta.** It is a diagnostic build for the multi-peer CPU-spike investigation tracked in `.planning/debug/cpu-spikes-beta12-regression.md`. Two suspect code paths are temporarily neutralized to confirm whether they are the regression source. Do **not** use this build for normal jamming — at high bitrates the original audio-cutoff bug that beta.20.1 fixed is intentionally re-introduced. Use beta.20.2 for normal use.
+
+### Diagnostic changes (NOT shipping fixes)
+- **ABTEST 1**: `DecodeMediaBuffer`'s SPSC ring temporarily reverted from 256 → 32 chunks. Confirms whether per-peer-per-interval 1 MB heap allocation churn (introduced by beta.20.1's ring bump) is the cause of audible CPU spikes that grow with peer count. Side effect: original interval-overflow cutoff bug returns at high bitrates (≥192 kbps stereo on 12 s intervals); `decbuf_drops` will climb in `/rcmstats`.
+- **ABTEST 2**: `broadcastBeatHeartbeat` call in `JamWideJuceEditor::timerCallback` is stubbed. Confirms whether ~1.5 Hz JSON build + WebSocket send on the message thread is the source of the baseline CPU bump that started showing in beta.12. Side effect: video companion sync indicator stops updating; no other functional impact.
+
+### Notes for testers
+- A/B compare baseline (beta.20.2) against this build under the same load (4+ peers, 30+ min session)
+- Watch for: (a) audible-glitch cadence change, (b) Activity Monitor CPU% baseline, (c) `decbuf_drops` counter via `/rcmstats`
+- Report findings to inform the proper fix (pool DecodeMediaBuffer + rate-limit/move heartbeat off message thread)
+
 ## [1.1.0-beta.20.2] - 2026-05-03
 
 ### Fixed

juce/JamWideJuceEditor.cpp

@@ -327,11 +327,18 @@ void JamWideJuceEditor::timerCallback()
     beatBar.update(bpi, beat, iPos, iLen);
 
     // Broadcast beat position to video companion page for sync indicator
+    // === ABTEST 2 (cpu-spikes-beta12-regression) — heartbeat broadcast stubbed.
+    //   Hypothesis: ~1.5 Hz JSON build + wsMutex_ acquisition + WebSocket send
+    //   is the source of the beta-12-onward baseline-CPU bump that users have
+    //   reported. Diagnosis build only. To restore: uncomment the if-block.
+    /*
     if (processorRef.videoCompanion && processorRef.videoCompanion->isActive())
     {
         int intervalCount = processorRef.uiSnapshot.interval_count.load(std::memory_order_relaxed);
         processorRef.videoCompanion->broadcastBeatHeartbeat(beat, bpi, intervalCount);
     }
+    */
+    // === END ABTEST 2
 
     // Update BeatBar BPM for label area display
     beatBar.setBpm(processorRef.uiSnapshot.bpm.load(std::memory_order_relaxed));

src/build_number.h

@@ -1,2 +1,2 @@
 #pragma once
-#define JAMWIDE_BUILD_NUMBER 313
+#define JAMWIDE_BUILD_NUMBER 314

src/core/njclient.cpp

@@ -354,7 +354,15 @@ class DecodeMediaBuffer
   // codec needed. 256 × 4 KB = 1 MB gives 2× headroom over that worst case.
   // Memory cost: 1 MB per concurrent RemoteDownload; with 30-peer rooms that
   // is ~30 MB transient, acceptable.
-  jamwide::SpscRing<jamwide::DecodeChunk, 256> m_chunks;
+  // === ABTEST 1 (cpu-spikes-beta12-regression) — diagnostic revert of 0e9cbae.
+  //   Hypothesis: 1 MB-per-buffer × N peers × per-interval allocation churn is
+  //   the audible-glitch cause. WARNING: this re-introduces the original
+  //   interval-overflow cutoff bug at high bitrates. Diagnosis build only.
+  //   To restore production sizing: change 32 back to 256. The proper fix is
+  //   to keep capacity at 256 but heap-allocate the ring storage or pool the
+  //   DecodeMediaBuffer instances per (peer_slot, channel_idx).
+  jamwide::SpscRing<jamwide::DecodeChunk, 32> m_chunks;
+  // === END ABTEST 1
 
   // Audio-thread-owned linear buffer — absorbs partial-chunk reads when the
   // codec asks for fewer bytes than CHUNK_BYTES at a time. Sized to 2x