Fix mislabeled CAF audio conversions on Linux clients

[andydoucet]

Problem

CAF voice-message downloads are converted with afconvert -f m4af -d aac, which produces AAC audio in an MPEG-4/M4A container. The server nevertheless gives the result a .mp3 suffix, changes the MIME type to audio/mp3, and can produce names such as Audio Message.mp3.mp3.

Players that trust the declared type or extension cannot determine the duration or decode the file. BlueBubbles 2.1.1.0 on two Linux clients displayed 0:00 / 0:00 and would not play these attachments, although the same files worked with more permissive Windows media handling.

This is related to the conversion command discussed in #799, but does not depend on that issue's upload race: successfully converted downloads are consistently mislabeled.

Reproduction evidence

Environment:

• BlueBubbles Server 1.9.9
• macOS 26.1 on Apple silicon
• BlueBubbles Linux Flatpak 2.1.1.0

For a server-generated file named Audio Message.caf.mp3 and served as audio/mp3, file and ffprobe reported:

audio/x-m4a
codec_name=aac
format_name=mov,mp4,m4a,3gp,3g2,mj2
duration=41.088000

The Linux client cached it as Audio Message.mp3.mp3 and rendered a zero-length player.

Fix

• Rename the conversion helper from CAF-to-MP3 to CAF-to-M4A to reflect what afconvert actually creates.
• Use an .m4a conversion path.
• Serve the result as audio/mp4.
• Normalize Audio Message.caf.m4a to the client-facing name Audio Message.m4a, avoiding a doubled extension.

This retains the native macOS conversion path and introduces no new runtime dependency.

Validation

• ESLint passes for both modified TypeScript files.
• git diff --check passes.
• The existing afconvert output was inspected with both file and ffprobe to confirm AAC in an M4A container.
• Full tsc --noEmit is currently blocked before source checking by the repository's existing ignoreDeprecations value in tsconfig.json (TS5103 under both the installed compiler and the declared TypeScript 5.5.2).