Audio recording playback fails and renamed downloads use incorrect file format

Description:

When users record and send an audio message, audio behavior is inconsistent in Storybook/local integration:

• Sent audio sometimes shows 0:00 / 0:00 and controls appear non-functional due to media URL access issues.
• If the attachment filename is renamed (especially without extension or with a wrong extension), download may use an incorrect format/extension.
• Console also shows related warnings errors (CORS/403 for file URLs, and DOM nesting warning in message rendering context).

Steps to reproduce:

1. Connect EmbeddedChat to local Rocket.Chat (http://localhost:3000) and run UI via Storybook (http://localhost:6006).
2. Record an audio message from chat input and send it.
3. Try to play the sent audio from message area.
4. Rename attachment name (e.g., hello or hello.txt) and download it.
5. Open browser console and observe network runtime warnings.

Expected behavior:

1. Sent audio should play normally (play button and seek slider functional).
2. Downloaded file should keep a valid audio format extension based on actual media type.
3. Renaming should not convert force audio into an incorrect extension.
4. No DOM nesting warnings for normal message rendering.

https://github.com/user-attachments/assets/9951d79d-98f8-41f2-980e-07396eb247e9

Actual behavior:

1. Audio media URL requests fail with 403 / CORS preflight errors in Storybook-to-Rocket.Chat setup.
2. Audio appears as 0:00 / 0:00 and playback is not usable.
3. Renamed downloads can end up with incorrect extension handling in some flows.
4. Console warning appears: validateDOMNesting(...): cannot appear as a descendant of

   .

https://github.com/user-attachments/assets/b251d1f4-1d7b-431c-a740-0d5c89396233

Start by reproducing the recording and renamed-download flows in Storybook against the local Rocket.Chat instance, then inspect the audio message, attachment download, and message-rendering entry points involved. Done means audio playback works, downloads retain an extension matching the actual media type, and the reported DOM nesting warning is gone.