FLEX-6500 — ~70s of RX audio silence after a CWX transmit (firmware-side?)

I am working on a new multiplatform Flex client. Having some really struggles implementing CWX.

I've hit a consistent, reproducible behavior on my FLEX-6500 (firmware v4.2.18.41174) and I'm hoping someone here can explain it or point to a fix.

Symptom: After sending CW via CWX (cwx send) on a CW slice, the remote_audio_rx (Opus) stream goes to digital silence for ~70 seconds. The radio returns to READY within ~2s and the panadapter/waterfall keep working — but there's no receive audio until it spontaneously resumes. SmartSDR does not do this.

Why I'm confident it's the radio, not my client:
Reproduced with a standalone Python probe talking straight to the radio's TCP API + VITA-49 audio stream — no third-party client involved. Audio frames keep arriving at 100/s but are all 3-byte Opus DTX (comfort-noise) frames, i.e. the radio is feeding silence into the encoder.
It's a fixed timer (~68–72s), not proportional to the CW: "TEST TEST TEST" @25wpm → 72.3s; a single dit "E" @50wpm → 68.2s.

The radio stays in READY the whole time and reports no status change (no audio_mute, squelch, or interlock event) — including at the instant audio returns.
Survives a full audio-stream disconnect/reconnect, so it's slice/radio-side, not per-stream.

Ruled out (each tested against the radio): still transmitting; stale CWX queue (cwx clear no effect); break-in/QSK; a plain MOX carrier (doesn't trigger it — it's CWX-specific); slice audio_mute/audio_level; leaving CW mode mid-outage; mute_local_audio_when_remote=0.

Questions for the group:
Does anyone know what SmartSDR does differently around CWX that avoids this — a different cwx command form/terminator, or does SmartSDR simply not depend on remote_audio_rx during CW?

Is this a known firmware behavior with a documented trigger, or a client-side lever to release the mute sooner?

Any pointers appreciated

NQ0S