How should we handle audio longer than a model can process? #5460

Many wrappers currently use a fixed 30s cap. This truncates models that natively support much longer audio, while also hiding the real limits of models that genuinely stop around 30s.

Proposed approach: use each model's own declared/native duration limit, then handle overflow based on model type:

• Conventional audio encoders → split into windows of that model's limit and mean-pool the embeddings. For models with no hard inference limit, use their training duration as the window size.
• Omni / LLM-based models → don't split; follow the native inference path and truncate only at the model's declared limit. Chunking and averaging partial-audio embeddings is not clearly meaningful here.
• Models that already aggregate long audio internally → pass the full clip and let the model handle it natively.

This also means that if one model supports longer audio than another, that remains a capability advantage rather than something we normalize away.

A few details still need to be decided:

• The final short chunk should be duration-weighted as suggested by @gowitheflow-1998

• how to handle memory/OOM issues for long-context models:
  @gowitheflow-1998: "we could add vllm support for audio/omni MLLM models where possible and validate they work identically as the original encoding implementation"

• exposing native audio limit in ModelMeta?

CC: @isaac-chung @KennethEnevoldsen @Samoed @gowitheflow-1998