fix: apply detune transpose before stretch processing and when detune returns to zero

[Slavezax]

⚠️ Breaking changes ⚠️

None.

Introduced changes

In AudioBufferBaseSourceNode::processWithPitchCorrection, stretch_->setTransposeSemitones(detune) is called after stretch_->process() and only when detune != 0. This causes two audible bugs on pitch-corrected sources:

1. First render quantum plays untransposed. A freshly created source with detune already set renders its first quantum before the transpose is ever applied to the stretcher. Since every start()/seek goes through a new source node, this produces an audible pitch glitch at the original pitch on every play/seek while detuned. Easy to hear with sustained tonal material (e.g. several stems playing pitch-shifted: each seek briefly "dips" to the original key).

2. Stale transpose when detune returns to 0. Because the setter is guarded by detune != 0.0f, once the param goes back to zero the previously set transpose is never cleared — the source keeps playing transposed even though detune is 0.

Fix: set the transpose unconditionally and before stretch_->process() so the stretcher always processes with the current detune value. setTransposeSemitones is cheap (it just updates the frequency multiplier), so calling it every quantum is fine.

We've been shipping this change as a patch-package patch in a production audio app (multi-stem playback with real-time pitch shifting) since 0.10.x and it eliminates both glitches.

Checklist

• Linked relevant issue
• Updated relevant documentation
• Added/Conducted relevant tests
• Performed self-review of the code
• Updated Web Audio API coverage
• Added support for web
• Updated old arch android spec file

🤖 Generated with Claude Code

[mdydek]

thank you for the contribution