fix(audio): return str for response_format="text" instead of a content-dependent type

[Kayvan-Zahiri]

audio.transcriptions.create and audio.translations.create hardcode cast_to=Transcription / cast_to=Translation regardless of response_format. Groq serves response_format="text" as text/plain, so _response.py falls back to response.json() and returns whatever type the transcript happens to parse as. The return type therefore varies with what the speaker said:

body='Hello there.'   -> str
body='42'             -> int
body='true'           -> bool
body='null'           -> NoneType
body='[1, 2]'         -> list
body='{"text": "hi"}' -> Transcription

With _strict_response_validation=True a plain English transcript raises APIResponseValidationError instead of returning.

The fix picks cast_to from response_format, the way openai-python does with _get_response_format_type, and widens the declared return to Transcription | str / Translation | str. _parse short-circuits on cast_to == str, so text now returns the exact body in both strict and loose mode. json / verbose_json / default are unchanged.

Added tests/test_audio_response_format.py: 28 of its 30 cases fail before the patch, all 30 pass after. tests/api_resources/audio/ stays at 16 passed / 44 skipped. ruff, mypy and pyright are clean on the changed files.

Overloads keyed on response_format would give exact per-format types, but that belongs in the Stainless config rather than a hand patch to generated files.

🤖 Generated with Claude Code