fix(icom): decode the network RX audio as what the rig actually sends

The first real radio on the 50003 stream (an IC-7760) settles the two guesses
the experimental audio path shipped with. The payload starts at 0x18 — the
packet carries a big-endian payload length at 0x14 (0x500 on every packet) —
not at 0x16, which swallowed two header bytes into the PCM and laid a 50 Hz
click track under everything. And rxcodec 0x10 asks for TWO-channel LPCM,
which the mono playback path rendered as double-speed garble; 0x02 asks for
the one channel the monitor plays.

internal/cat/icomaudio.go

@@ -28,11 +28,13 @@ import (
 	"time"
 )
 
-// icaAudioOffset is where the PCM payload begins inside an audio data packet
-// (wfview audio_packet: 16-byte common header + ident@0x10 + datalen@0x12 +
-// sendseq@0x14 → audio@0x16). Isolated as a const so a capture-confirmed change
-// is a one-line edit.
-const icaAudioOffset = 0x16
+// icaAudioOffset is where the PCM payload begins inside an audio data packet.
+// CONFIRMED on a real IC-7760 (2026-08-29): 16-byte common header, ident@0x10,
+// send seq (BE) @0x12, payload length (BE uint32) @0x14 — 0x500 observed on
+// every packet — and the PCM starts at 0x18. The 0x16 first guessed from
+// wfview's struct swallowed two header bytes into the audio, one broken sample
+// per packet: a 50 Hz click track under everything.
+const icaAudioOffset = 0x18
 
 // icaDumpFirst is how many initial audio packets to hex-dump to the debug log for
 // offset verification. After the layout is confirmed on a real rig this can go to