[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>

trx-rs.toml.example

@@ -63,6 +63,8 @@ wspr_file = "TRXRS-WSPR-%YYYY%-%MM%-%DD%.log"
 
 [trx-server.sdr]
 sample_rate = 1920000
+spectrum_fft_size = 1024
+spectrum_interval_ms = 50
 bandwidth = 1500000
 wfm_deemphasis_us = 50
 center_offset_hz = 100000
@@ -90,6 +92,7 @@ log_level = "info"
 url = "192.168.1.100:9000"
 rig_id = "hf"
 poll_interval_ms = 750
+spectrum_interval_ms = 50
 
 [trx-client.remote.auth]
 token = "my-token"