fix: use file name instead of 'a voice message' for non-voice audio

[mvanhorn]

Description

Only labels audio files as "a voice message" when they actually are voice messages (have waveform data). Regular audio files (music, podcasts) now use the file name as the body text instead.

Fixes #543

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings

AI disclosure:

• Partially AI assisted (clarify which code was AI assisted and briefly explain what it does).
• Fully AI generated (explain what all the generated code does in moderate detail).

The isVoice check logic was written alongside an AI tool. It checks whether the audio message event contains waveform data in content.info to distinguish voice messages from regular audio file uploads. If waveform data is absent, the message body falls back to the file name from content.body instead of the hardcoded "a voice message" string.

[dozro]

hey it seems like you're missing a changeset. Can you please add a changeset, as described here https://github.com/SableClient/Sable/blob/dev/CONTRIBUTING.md#documenting-a-change

Thank you :3

and to the change: i don’t know if it’s good UX if it then just throws a filename at the recipient in the notification (iirc the body is used in notifications)

[mvanhorn]

Changeset added, and I've updated the PR description to follow the template with AI disclosure. Appreciate the pointer.

[7w1]

and to the change: i don’t know if it’s good UX if it then just throws a filename at the recipient in the notification (iirc the body is used in notifications)

Definitely better than throwing "a voice message" for files that aren't voice messages, though. Don't see how we could get any other info about the file beyond file name unless the sender adds caption/alt text with the file

[dozro]

Definitely better than throwing "a voice message" for files that aren't voice messages, though. Don't see how we could get any other info about the file beyond file name unless the sender adds caption/alt text with the file

maybe passing along if it’s a voice message and then set it to “a voice message” 🤔 , idk tho

[mvanhorn]

That's already what this PR does - it checks for waveform data to distinguish voice messages. Voice recordings get 'a voice message', other audio files get the filename. See isVoice on the diff.