fix[vLLM x v5]: Default untied embeddings in AudioFlamingo3 and VibeVoice

[harshaljanjani]

What does this PR do?

→ Fixes vllm-project/vllm#39330 (comment)
→ Corrects the tie_word_embeddings default for AudioFlamingo3 and VibeVoice for integration with the vLLM Transformers backend. This only causes issues with vLLM and not Transformers because Transformers always loads checkpoint weights regardless of tie_word_embeddings (or in other words, it's a hint for init-time tying, not a directive as in vLLM to my understanding).
→ Made sure this doesn't cause any regressions in tests/models/audioflamingo3/ and tests/models/vibevoice_asr/

Model-wise behavior

→ AudioFlamingo3 and VibeVoice: These models break under the current default; their checkpoints contain distinct lm_head and embed_tokens weights (with a max difference of ~1.0 to 1.7). Substitution produces garbage outputs.
→ GraniteSpeech: Works fine as-is because it genuinely ties its embeddings and has no separate lm_head in the checkpoint.
→ GLM-ASR: Works fine as-is. It has separate lm_head and embed_tokens, but they are bitwise identical (max diff = 0.0), so tying them produces the same result.

cc: @eustlb @vasqu

Code Agent Policy

• I confirm that this is not a pure code agent PR.

Before submitting

• This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
• Did you read the contributor guideline, Pull Request section?
• Was this discussed/approved via a Github issue or the forum? Please add a link to it if that's the case.
• Did you make sure to update the documentation with your changes? Here are the documentation guidelines, and here are tips on formatting docstrings.
• Did you fix any necessary existing tests?

[github-actions]

[For maintainers] Suggested jobs to run (before merge)

run-slow: audioflamingo3, vibevoice_asr

[vasqu]

LGTM but cc @ebezzam to double-check (I think you were involved in those models?)

In general iirc, we only tie if we also really detect missing keys so really might as well be skipping those parts

[ebezzam]

@vasqu thanks for the ping. Those lines were added with the refactor from #45534
Probably accidental, so I think we can remove altogether (rather than setting to False) as you suggest.

Unless @eustlb you had found a reason to set them to True?

[eustlb]

Yep, it slipped through... Thanks a lot for catching @harshaljanjani ! Agree that simply removing the field is better here

[github-actions]

CI Dashboard: View test results in Grafana

[HuggingFaceDocBuilderDev]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.