Summary

Low-severity / cosmetic follow-up to #3892 (fix(audio): TCI TX resamples from client-declared rate). Telemetry-naming only — no audio or timing impact.

Detail

Before #3892, the TCI TX path always resampled from a hardcoded 48 kHz, so the per-session input-frame counter m_txInputFrames (and the inputFrames48k local that feeds it) genuinely held 48 kHz frame counts. #3892 correctly changed the resampler to use each frame's declared rate (hdr.sampleRate), but left the 48k naming in place:

• src/core/TciServer.cpp:927 — int inputFrames48k = 0;
• src/core/TciServer.cpp:1043 — m_txInputFrames += inputFrames48k;
• src/core/TciServer.cpp:~1783 — soak log: << " input48k=" << m_txInputFrames

For a client that negotiates a non-48 kHz audio_samplerate (8/12/24 kHz) and transmits, inputFrames48k now accumulates source-rate input frames, so the input48k=N soak diagnostic implies the wrong wall-clock duration (e.g. a 24 kHz client reads as ~2× its real input duration if N is interpreted as 48 kHz frames).

m_txInputFrames is diagnostic-only — its only consumers are the reset in startTxChrono, the increment here, and the soak log line. Nothing in the audio/timing path reads it, so this is purely a misleading-label issue, not a correctness bug. (WSJT-X is 48 kHz, so the common path is unaffected either way.)

Proposed fix

Rename for accuracy:

• inputFrames48k → inputFrames (or inputFramesSrcRate)
• soak log field input48k= → inputFrames=

Optionally, if a true 48k-equivalent duration is wanted in the soak line, scale by txSrcRate / 48000.0 instead — but a plain rename is the lighter, clearer fix.

Refs #3892, #3306.