RX DSP stereo balance (#4135) follow-up: document envelope-only NR + pan contract; RN2/BNR latency; probe stall

Follow-up from the review of #4135 (Preserve RX DSP stereo balance). That PR's six blocking findings were all resolved and it's approved/merging; these items are the accepted-but-undocumented behavior changes and two residual polish items, split out so #4135 can land.

Document the behavior changes (the main ask)

1. Envelope-only NR for stereo content

MonoDspStereoAdapter (used by RN2/NR4/MNR/DFNR/BNR) applies the mono engine's gain envelope to the dry L/R when true stereo is present, instead of the engine's spectral output. For a centered slice (L≈R, the common case) the full processed waveform passes through, so nothing changes; but on genuinely stereo/panned RX, DFNR/BNR become proportional ducking rather than spectral denoising. This tradeoff is intentional and accepted, but there is currently no UI or docs indication that NR behaves differently on stereo audio.

• Add a short note in the NR/help docs (and consider a subtle UI hint) that spectral NR is full-strength on mono/centered audio and reduces to balance-preserving envelope attenuation when stereo separation is present.
• Document/justify the kStereoDetectionRatio = 1e-4 threshold in MonoDspStereoAdapter.cpp — below it, <~1% L/R separation is treated as mono and collapsed. Confirm that cutoff is where we want it.

2. RX pan contract change

#4135 reworked pan so external Kiwi sources carry independent pan and m_rxPan "must not retarget Kiwi." Two user-visible consequences need confirming + documenting, and the GUI/mirroring reconciled to match the chosen semantics:

• Whether the client pan slider still does anything for Flex NR output (the radio-applied per-slice pan now survives NR, which is the point of the PR — but the slider may now be inert for Flex).
• Whether syncFlexRxPanToAudioEngine mirroring the Flex slice's audioPan into m_rxPan now silently steers only the legacy-Kiwi stream.

Residual engineering polish (lower priority)

3. Latency compensation for RN2 and BNR

SpecbleachFilter/DeepFilterFilter pass their processing latency to the adapter; RNNoiseFilter and NvidiaAfxFilter do not (adapter runs at latency=0). On stereo content through RN2/BNR the gain envelope lags the engine's internal delay, mildly ducking syllable onsets. RNNoise's latency is roughly fixed/knowable; NVIDIA AFX exposes no latency getter, so BNR may need a measured/estimated constant.

4. probeDspStereo runs synchronously on the bridge thread

audioCapture probeDspStereo all strict cold-inits DeepFilterNet/NVIDIA AFX and runs ~3 s of audio inline in the socket callback with no yield — the app reads as hung and the python probe can hit its socket timeout and report a spurious failure. Automation-only. Chunk it through the event loop or document the expected duration and raise the probe-side timeout. (The multi-token mode-arg error was already added in #4135.)

Start with MonoDspStereoAdapter.cpp and the NR/help documentation, then review the pan behavior around m_rxPan and syncFlexRxPanToAudioEngine. Check latency handling in SpecbleachFilter, DeepFilterFilter, RNNoiseFilter, and NvidiaAfxFilter, and the audioCapture probeDspStereo entry point. Done means the accepted stereo NR and pan contracts are documented, latency and probe behavior are addressed, and the relevant semantics are confirmed.