Realtime: committed-utterance WAV written with fixed 16 kHz header breaks 24 kHz client commits (empty STT -> input_not_committed -> total silence) #12747

Bug

In the OpenAI-Realtime pipeline, the client-commit path writes the committed
utterance to a temp WAV with a fixed 16 kHz header
(laudio.NewWAVHeader(uint32(len(utt))) in commitUtteranceWithTranscript,
and writeUtteranceWAV), while the input buffer holds audio at the
session input sample rate (e.g. 24 kHz for OpenAI-Realtime clients —
session.update audio.input.format.rate = 24000).

The file-based transcription backend then decodes 24 kHz PCM data with a
16 kHz header (1.5x speed/pitch), degrading transcription to garbage or
empty output. An empty transcript fails the follow-up response with
input_not_committed → total silence after the greeting (no reply at
all, recovery phrases not triggered either).

Reproduction

1. Start a realtime session with audio.input.format.rate = 24000 and
   turn_detection: null (client-driven commits).
2. Stream ~2 s of speech, send input_audio_buffer.commit.
3. The committed WAV (temp file realtime-audio-chunk-*.wav) carries a
   16 kHz header; the transcription of 24 kHz content at 16 kHz is garbage
   or empty → response.done failed input_not_committed.

Offline proof: identical audio transcribes cleanly with a 24 kHz header and
produces empty output with a 16 kHz header.

Fix

writeUtteranceWAV takes the sample rate; both call sites pass
session.InputSampleRate via the existing laudio.NewWAVHeaderWithRate
(PR follows).

Impact

Every client-commit session with an input rate other than 16 kHz
(WebRTC sessions resample to 16 kHz and are not affected).