Feature: Add audio file attachment upload and sending in chat

[mjkatgithub]

Goal

Enable users to pick existing audio files from device storage and send them as
chat audio attachments.

Scope

• Add audio file picker support in message input (PC and smartphone flow).
• Validate supported MIME types (e.g. audio/mpeg, audio/mp4, audio/ogg,
  audio/wav, audio/webm).
• Validate maximum file size before upload with clear errors.
• Upload selected audio via existing media upload flow/backend endpoint.
• Send uploaded file as chat audio message with media metadata.
• Render audio attachments in timeline with playback controls.
• Show upload/sending states (loading, success, error).
• Add/extend tests for picker, validation, upload, send, and rendering.

Branch

feature/audio-file-attachments

Acceptance Criteria

• User can select audio files from local device storage.
• Unsupported file types are blocked with user-friendly feedback.
• Oversized files are blocked with user-friendly feedback.
• Valid audio file uploads and sends successfully.
• Sent audio message appears in timeline and is playable.
• Upload/send errors are visible and understandable.
• Existing text/image/video flows remain unchanged.

Test Checklist

Unit

• File type and size validation for selected audio files.
• Audio attachment message payload creation.
• Upload/sending/error UI state transitions.

Integration

• Audio upload returns media URL/metadata as expected.
• Chat send flow creates and renders audio message events.
• Backend/API errors are surfaced correctly in UI.

E2E

• User selects and sends a valid audio file in a room.
• Receiver sees and plays the audio attachment.
• Invalid/oversized file shows clear validation feedback.

Notes

• This issue is only for selecting existing files from device storage.
• In-app microphone recording is handled in a separate feature.

Protocol/Compatibility Notes (Matrix)

• Send as m.room.message audio event for broad compatibility.

• Include sufficient audio metadata (mimetype, size, duration if known).

• For voice recordings, include voice-message specific markers where supported.

• Always provide fallback rendering as regular audio (m.audio) for clients
  without voice-message UI support.

• Verify behavior against at least one modern Matrix client and one older/basic
  client rendering path.

• Audio file attachments are treated as standard m.audio events without
  requiring voice-message specific UI semantics.