Accept string audio languages from ffprobe

[iCosiSenpai]

This fixes a small but real ffprobe parsing bug around audio language detection.

Root cause

In a couple of places Bazarr assumes detected_language["language"] is always an object exposing .alpha3.

That is not always true. In the cases I hit, ffprobe metadata surfaced the language as a plain string such as jpn.

Because of that, Bazarr either:

• raised 'str' object has no attribute 'alpha3'
• or skipped the track and left audio_language empty

What changed

• accept both language objects and plain strings in subtitles/refiners/ffprobe.py
• accept both in utilities/video_analyzer.py
• add tests covering string-based ffprobe audio language values

Why this matters

This directly affects library state, not just logging. A file can be tagged correctly on disk and Bazarr will still keep it in the unknown audio set because the ffprobe path never turns that string value into a usable alpha3 code.

Validation

• added unit tests for _handle_alpha3({"language": "jpn"})
• added a test for embedded_audio_reader() with ffprobe audio metadata returning {"language": "jpn"}
• smoke-checked the same logic against a live Bazarr 1.5.6 instance where a previously affected movie started repopulating audio_language after the patch

Closes 3307

[morpheus65535]

Could you check if the returned string is a valid language? If it's "garbage", we don't want to break something else further down the road.