TxVoiceProcessor config is re-pushed every 10 ms block instead of on change

Follow-up from PR #4875 (48 kHz TX voice refactor), finding 5 of @jensenpat's review. Non-blocking there; recorded here so it is not lost.

The problem

AudioEngine::onTxAudioReady() re-pushes processor configuration into TxVoiceProcessor on every capture callback (~10 ms):

m_txVoiceProcessor->setStageOrder(m_txChainPacked.load(std::memory_order_acquire));
m_txVoiceProcessor->setMicGain(m_pcMicGain.load());
m_txVoiceProcessor->setRnnoiseEnabled(m_rn2TxEnabled.load());

These are cheap (relaxed atomic loads feeding plain stores), so this is not a performance concern. The concern is structural: configuration stays correct only because one call site remembers to mirror it. Any future setter that forgets to add its line here goes silently out of sync — the classic config-drift shape.

Partially addressed in #4875: the constant setMeasurementCaptureEnabled(false) call was removed from the block path entirely.

Why it was deferred

Moving to change-notification introduces a synchronisation seam between the owner thread and the audio thread. #4875 was already reworking RN2 ownership and publication semantics in the same area (setRnnoise() is now the single publication point with release/acquire), and stacking a second concurrency change in the same release was judged unwise.

Suggested direction

Publish config through the same ownership-seam pattern setRnnoise() now uses, so the audio thread reads published state rather than having the call site push it. Worth doing after #5013, since both touch the same publication surface.

Start with AudioEngine::onTxAudioReady() and the TxVoiceProcessor setters shown in the issue. Read the setRnnoise() publication path and issue #5013 before changing the ownership seam. Done means configuration is published through that seam rather than re-pushed on every capture callback, while remaining synchronized on the audio thread.