feat(tci): answer the radio's requests instead of pushing audio at it

Three transmissions on a real SunSDR settled how the transmit side works,
and none of it was guessable from the documentation.

The radio asks for audio only when the transmission is the CLIENT'S: with
the operator keying the microphone it sent 282 receive frames and nothing
else. And it asks only in a DIGITAL mode — keyed from here in SSB it stayed
silent four times over, and answered in DIGU immediately. In SSB the
modulator is wired to the microphone, which is also the honest answer to
'why can I hear myself but not the tone'.

The chrono turns out to be a REQUEST, not a clock. It carries no payload —
the message itself is the ask — and it names the size it wants in the
header: 2048 samples, two channels interleaved, 47 times a second, which
is 1024 pairs at 48 kHz, exactly real time.

So audio goes out in answer to a request and never on a timer of our own.
The timer was the first attempt and the radio ignored all 234 frames of
it. Answering also hands the pacing to the radio: no drift, no buffer to
tune, and the size taken from what it asked for rather than from what we
assumed. The sine keeps its phase across frames, since one restarted every
frame is a click 47 times a second.

A pass in SSB is now refused rather than attempted. It keys the
transmitter, produces nothing and teaches nobody anything — and it is
still a transmission.

The feed mechanism is the one the voice keyer will use: WAV samples in
place of the sine, everything else unchanged.

internal/cat/tci_audio.go

@@ -92,13 +92,22 @@ type tciAudio struct {
 	// widthLogged keeps the one-line note about the sample width to once a
 	// session — it is a fact about the radio, not an event.
 	widthLogged bool
+	// txMark is the per-type frame count when transmission began, so the census
+	// at the end reports the pass rather than the whole session.
+	txMark map[int]int64
+
+	// txFeed supplies the next frame of transmit audio when the radio asks for
+	// one, or is nil when nothing is being sent. Set under this same lock, and
+	// read on the reader goroutine — the radio's request and our answer are two
+	// halves of one exchange and must not straddle a race.
+	txFeed  func(samples int) []byte
+	txSent  int64
+	txShort int64 // requests the feed could not fill (it had run out)
+
 	// What the radio SAID about its stream at connect (audio_stream_sample_type,
 	// audio_stream_channels). Its own declaration, and it arrives before the
 	// first frame — the frame arithmetic below stays as the check on it rather
 	// than as the only source.
-	// txMark is the per-type frame count when transmission began, so the census
-	// at the end reports the pass rather than the whole session.
-	txMark        map[int]int64
 	declaredType  string
 	declaredChans int
 
@@ -215,11 +224,17 @@ func (t *TCI) handleBinary(data []byte) {
 			receiver, rate, format, codec, length, stype, len(data)-tciHeaderBytes)
 	}
 
+	if stype == tciStreamTXChrono {
+		// The radio asking for the next frame of transmit audio. It is empty —
+		// the whole message IS the request — and it carries the size it wants in
+		// the header's length field, so the answer is written from what it says
+		// rather than from what we assumed.
+		t.serveChrono(rate, length)
+		return
+	}
 	if stype != tciStreamRXAudio {
-		// IQ, transmit audio, chrono. Nothing consumes them yet — but the chrono
-		// frames are what a voice keyer over TCI would have to answer, and their
-		// size and cadence cannot be guessed from the documentation. They are
-		// logged (per type, see above) and dropped.
+		// IQ and transmit audio. The latter is ours to send, not to receive:
+		// counted above, and dropped.
 		return
 	}
 	if codec != 0 {