#32: correct the stale "no field complaints since" note + record the frame-time A/B

Found while checking whether a player had reported this before: the code already
carried a prior analysis of this exact error which deliberately decided NOT to
act on it, concluding the 2026-07-23 atomic-delete fix (a999e5c) had settled it
with "no field complaints since", and that the remaining exhaustion was
transient and likely sub-perceptual.

That claim did not hold, and the note was still sitting there to mislead the next
reader.  All five 4.11.674 player logs are saturated: 3031/4657/5245/6275/6571
failures, first one ~10% into a match, still failing at 97%.

The prior note's core reasoning was about raising the source BUDGET -- more
voices mixing = more CPU during heavy combat -- and it is sound; BT_AUDIO_SOURCES
stays opt-in and unset.  But it does not apply to pooling, which changes no
budget: idle pooled sources are stopped and detached and cost nothing to mix.
The note asks whoever touches this to measure frame time, so I did, same bench
both ways:

    pre-fix   8.672 ms weighted avg over  9390 frames
    post-fix  7.794 ms weighted avg over 10047 frames

Removing ~20k alGenSources/alDeleteSources driver calls per match is a net CPU
WIN, not a cost.  Single run each, so indicative rather than definitive, but it
points the opposite way from the concern.

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

engine/MUNGA_L4/L4AUDRND.cpp

@@ -395,12 +395,27 @@ void
 		// DPLIndependantEffect voices, and while the pool is pinned every new
 		// acquire fails outright and that sound is silently dropped.
 		//
-		// ⚠ OFF BY DEFAULT, DELIBERATELY.  Raising the cap is NOT a free win, and
-		// the reported dropout was already fixed on 2026-07-23 by a999e5c (the
-		// atomic-delete leak) -- no field complaints since.  What remains in the
-		// night-5 logs is transient exhaustion at the peak of a firefight, where
-		// a dropped voice competes with ~256 already sounding, so it is very
-		// likely sub-perceptual.  Against that: the 256 ceiling also acts as a
+		// ⚠ OFF BY DEFAULT, DELIBERATELY.  Raising the cap is NOT a free win.
+		//
+		// ⚠⚠ UPDATE 2026-08-01 (#32): the "no field complaints since" claim below
+		// did NOT hold.  Every 4.11.674 player log is saturated -- 3031/4657/5245/
+		// 6275/6571 failures across five machines, first failure ~10% into a match
+		// and still failing at 97%.  The root cause was NOT the source budget at
+		// all: RequestAudioChannels was alGenSources'ing per sound event and
+		// ReleaseSourceSet alDeleteSources'ing on release, so combat CHURNED
+		// through the ceiling.  Sources are now POOLED and recycled (see
+		// BTAudioPoolAcquire below), which fixes it WITHOUT touching this budget.
+		// Measured on the same bench: frame time went 8.67ms -> 7.79ms over ~10k
+		// frames, i.e. removing the churn is a net CPU WIN, so the governor
+		// argument below does not apply to pooling.  The reasoning about raising
+		// the CAP (more voices mixing = more CPU) still stands on its own, which
+		// is why BT_AUDIO_SOURCES remains opt-in and unset by default.
+		//
+		// (Historical:) the 2026-07-23 fix a999e5c addressed the atomic-delete
+		// leak.  What remained in the night-5 logs is transient exhaustion at the
+		// peak of a firefight, where a dropped voice competes with ~256 already
+		// sounding, so it is very likely sub-perceptual.  Against that: the 256
+		// ceiling also acts as a
 		// GOVERNOR.  The steal loop only steals when the incoming source outranks
 		// a running one, so a higher cap means many more voices mixing at once --
 		// with EFX reverb + the lowpass chains live, that is real CPU, spent