fix(realtime): normalize non-string audio formats in length calc

[adityasingh2400]

Summary

calculate_audio_length_ms (in src/agents/realtime/_util.py) only inspected the format argument when it was a str. The RealtimeAudioFormat type alias also accepts:

• the OpenAIRealtimeAudioFormats pydantic models (AudioPCM, AudioPCMU, AudioPCMA)
• Mapping[str, Any] such as {"type": "audio/pcmu"}

In both cases the function fell through to the PCM16 branch and computed duration at 24 kHz with a 2-byte sample width. For g711 audio that overstates the length by ~6x, which feeds the wrong elapsed_ms and audio_length_ms into ModelAudioTracker / RealtimePlaybackTracker and ultimately breaks interrupt truncation timing whenever a caller wires the format through as anything other than the canonical pcm16 / g711_ulaw / g711_alaw strings.

This PR:

• Adds _extract_format_type to read the format type from strings, mappings, and pydantic models uniformly.
• Recognizes the wire-format aliases audio/pcmu / audio/pcma (returned by _normalize_audio_format for some payloads) as g711.
• Preserves the historical behavior: empty bytes return 0.0, unknown formats fall back to PCM16, and case-insensitive matching is retained.

The fix is a 22-line surgical change in _util.py plus a focused test module covering pydantic models, mappings, the audio/pcmu alias, uppercase strings, unknown-format fallback, and empty bytes.

Test plan

• pytest tests/realtime/test_audio_length_format_normalization.py (new, 7 cases, all pass)
• pytest tests/realtime full suite still green (239 passed)
• Existing test_calculate_audio_length_ms_pure_function (in test_openai_realtime.py) still passes — string-input behavior unchanged

[adityasingh2400]

Closing as duplicate of #3196 (same wave, my own oversight). #3196 adds the equivalent _normalize_format_to_str helper for str/Mapping/pydantic-typed formats and matches both g711_* prefix and audio/pcm{u,a} aliases. Sorry for the noise — please review #3196 instead.