[feat](trx-rs): make spectrum affordable over a slow link

Spectrum dominates the server↔client connection, and all three things that
govern its cost were working against a poor link.

**It was polled, one round trip per frame.** The client asked for a frame every
50 ms on a dedicated connection and waited for the reply, so the frame rate was
capped at 1/RTT — on a 200 ms link, five frames a second no matter what was
configured.  Add SubscribeSpectrum alongside the existing SubscribeMeter: the
server pushes frames from a per-rig broadcast that rig_task fills only while
somebody is subscribed.  A server too old to know the command answers with an
error and leaves the connection usable, so the client falls back to polling on
the same connection without reconnecting.

**Bins were JSON floats.** 1024 bins spelled out as decimal text is around
10 KB a frame, ~200 KB/s at full rate — while the very next hop, client to
browser, already sends the same information as base64 i8 in about 1.4 KB.  Bins
now travel base64-encoded whole dBFS, the resolution the display draws at
anyway.  Decoding still accepts the old array form.

**Nothing was tunable.** [sdr].spectrum_fft_size and [sdr].spectrum_interval_ms
replace the compile-time FFT size and cadence; [[remotes]].spectrum_interval_ms
lets the client ask for less.  512 bins at 5 frames/s is roughly 3.5 KB/s
against roughly 200 KB/s before.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SyX26FCpMQxiBoC7r5K1A7
Signed-off-by: Stan Grams <sjg@haxx.space>

docs/User-Manual.md

@@ -153,6 +153,13 @@ When audio is enabled, at least one of `rx_enabled` or `tx_enabled` must be true
 | `sample_rate` | u32 | `1920000` | IQ capture rate in Hz |
 | `bandwidth` | u32 | `1500000` | Hardware IF filter bandwidth in Hz |
 | `center_offset_hz` | i64 | `100000` | Offset from dial to avoid DC spur |
+| `spectrum_fft_size` | usize | `1024` | Spectrum FFT bins; power of two, 128–8192 |
+| `spectrum_interval_ms` | u64 | `50` | How often a spectrum frame is pushed to subscribed clients |
+
+Spectrum is the largest thing on the client connection. On a slow or
+high-latency link, halving `spectrum_fft_size` halves the bytes per frame (at
+half the frequency resolution) and raising `spectrum_interval_ms` sends fewer of
+them; see [Spectrum over a slow link](#spectrum-over-a-slow-link).
 
 #### `[sdr.gain]`
 
@@ -295,6 +302,7 @@ Rigs without an explicit `id` get auto-generated IDs like `ft817_0`, `soapysdr_1
 |-------|------|---------|-------------|
 | `url` | string | — | Server address (e.g. `localhost:4530`) |
 | `poll_interval_ms` | u64 | `750` | State poll interval |
+| `spectrum_interval_ms` | u64 | `50` | Spectrum frame interval; also settable per `[[remotes]]` entry |
 
 #### `[remote.auth]`
 
@@ -394,6 +402,41 @@ older single `port` key and `--rigctl-port` are ignored.
 The bridge is intended for WSJT-X integration via virtual audio devices (ALSA
 loopback on Linux, BlackHole on macOS).
 
+### Spectrum over a slow link
+
+Spectrum dominates the server↔client connection: everything else is a few
+hundred bytes, a frame is a few kilobytes. Three things govern what it costs.
+
+**Frames are pushed, not polled.** The client subscribes and the server sends
+frames at `[sdr].spectrum_interval_ms`. Polling cost a round trip per frame, so
+the rate was capped at 1/RTT — on a 200 ms link you could not exceed 5 frames a
+second however often the client asked. Clients fall back to polling
+automatically against a server too old to stream.
+
+**Bins travel as whole dBFS.** They are base64-encoded `i8` on the wire, about
+an eighth of the JSON array of floats they used to be, at the resolution the
+display draws anyway.
+
+**Both ends have a rate, and the slower one wins.** The server pushes no faster
+than `[sdr].spectrum_interval_ms`; the client asks for no more than
+`[[remotes]].spectrum_interval_ms`.
+
+For a link that struggles, start here:
+
+```toml
+[trx-server.sdr]
+spectrum_fft_size = 512      # half the bins, half the bytes
+spectrum_interval_ms = 200   # 5 frames/s instead of 20
+
+[[trx-client.remotes]]
+name = "remote-site"
+url = "radio.example.com:4530"
+spectrum_interval_ms = 200
+```
+
+That is roughly 0.7 KB per frame at 5 frames/s — about 3.5 KB/s, against
+roughly 200 KB/s for 1024 float bins at 20 frames/s.
+
 ### CLI Override Summary
 
 **trx-server:**