fix(realtime): truncate audio at zero elapsed time - #4457

Four tests in TestSendEventAndConfig seed audio and interrupt on the next
statement, so they assume the clock advanced in between. time.monotonic()
on Windows is GetTickCount64() with a 15.625ms resolution, so both reads
land in the same tick, elapsed_ms is exactly 0.0, and the truncate path
under `if elapsed_ms > 0` never runs:

    test_normal_interrupt_targets_response_and_interrupts_audio
    test_interrupt_respects_auto_cancellation_when_not_forced
    test_interrupt_force_cancel_overrides_auto_cancellation
    test_interrupt_honors_falsy_present_session_auto_cancellation

They pass in CI, so whether they run depends on the ambient system timer
resolution rather than on the code under test.

Backdate initial_received_time, which is the idiom the same file already
uses in test_speech_started_skips_truncate_when_audio_complete. No
production code changes: the tests become deterministic on any host, and
the separate question of whether the `> 0` guard should treat a
sub-tick elapsed time as "no audio played" is left to openai#4456.

Per review on openai#4457: address the runtime behaviour rather than working
around it in the tests.

_interrupt_audio_playback gated truncation on `elapsed_ms > 0`, so an
interrupt arriving inside one clock tick was treated as "nothing to
truncate". That is a reachable state, not a contrived one:
time.monotonic() advances in ~15.6ms steps on Windows, so an interrupt in
the same tick as the audio it interrupts produces exactly 0. The item
then kept audio the user never heard, which is the condition truncation
exists to prevent.

The guard becomes `>= 0`. The branch's own log line already read
"Didn't interrupt bc elapsed ms is < 0", so the message described the
intended condition while the code did something narrower; it is now
accurate. truncated_ms already clamped through max(int(elapsed_ms), 0),
so a zero elapsed time needed no other handling.

Behaviour preserved deliberately: a negative elapsed time still skips,
a missing item id or elapsed value still skips, and the completed-audio
and max_audio_ms clamping paths are untouched.

Tests: the four five-second backdates are removed. They avoided the zero
case rather than covering it, and — as the review noted — pushed each
100ms fixture past its buffered duration, so the ongoing-response and
clamping path could satisfy them without active playback ever running.
Two deterministic tests replace them, pinning both monotonic readings to
the same value: one asserts audio_interrupted and a
conversation.item.truncate with audio_end_ms=0, the other asserts a
backwards clock still truncates nothing.