KiwiSDR wf_share=1: client discards the waterfall on channels with rx_chan >= wf_chans

What happens

On KiwiSDR v1.900+ receivers configured with a shared waterfall (rx8.wf3, wf_share=1, e.g. kphsdr.com and kiwisdr.kfsdr.com), every receive channel gets a waterfall, but AetherSDR marks the waterfall unavailable whenever the session lands on rx_chan >= wf_chans and shows the "KiwiSDR waterfall unavailable" overlay with the radio's own waterfall underneath. On an 8-channel receiver that throws away a real waterfall on 5 of 8 slots.

Why

KiwiSdrClient::updateWaterfallAvailability() gates on m_waterfallRxChannel >= m_waterfallChannelCount only; the client never parses wf_share (grep -rn wf_share src/ is empty).

Upstream server (rx/rx_waterfall.cpp): wf->isWF = (rx_chan < (kiwi.wf_share ? rx_chans : wf_chans) && conn->isWF_conn); the setup burst still advertises wf_chans=3 (the DDC count) next to wf_share=1. The stock browser client gates the same way: wf.audioFFT_active = ((rx_chan >= wf_chans && !kiwi.wf_share) || wf.no_wf) (openwebrx.js).

Expected

Parse wf_share on the W/F stream and treat rx_chan < rx_chans as waterfall-capable when wf_share=1, mirroring the stock client's rx_chan >= wf_chans && !wf_share gate. A socket-free replay of a v1.900 setup burst with rx_chan=5 wf_chans=3 wf_share=1 should assert waterfallAvailable() == true.

Related: the zoom_cap scale regression (separate issue) affects the channels that do get a waterfall; this one is about the channels that should.

Start with KiwiSdrClient::updateWaterfallAvailability() and the W/F stream setup parsing; grep the src/ tree for the existing waterfall fields, then compare the stock gate in openwebrx.js. Replay a setup burst with rx_chan=5, wf_chans=3, and wf_share=1, and verify that waterfallAvailable() returns true without a socket connection.