Add inline playback for regular audio attachments - #6666

Goal

Attachments with type: "audio" rendered as a generic file card, so an audio file sent from another platform looked broken on Android while playing inline on web. Give them a first-party inline player in Compose, using the attachment's assetUrl and filename, without requiring waveform data or a duration.

Closes #6611
Closes AND-1360

Implementation

• An inline audio player: play/pause toggle, file name, elapsed time, seek bar and file type icon, matching the Mobile / Message View Attachment / Audio File design. Progress and duration come from the player, so nothing extra is needed on the attachment.
• Audio keeps sharing the file attachment path. The default FileAttachmentItem delegates audio to a new ChatComponentFactory.AudioAttachmentItem slot, so integrators overriding FileAttachmentContent or FileAttachmentItem keep rendering audio exactly as they do today. AND-1439 tracks giving audio its own path in the next major, matching iOS and React.
• AudioPlayerController accepts AttachmentType.AUDIO alongside audio_recording, and takes the track duration from the player when the attachment carries none. A seek made before the duration is known is held per track and applied on the first progress update that reports one, so scrubbing an unplayed audio file starts from the thumb rather than from zero. The player divides by the duration it reports, which can be zero for a track it cannot measure, so the progress the UI reads is now sanitised against NaN.
• Audio uploads are now typed audio instead of file, in AttachmentMetaData, StorageHelper and AttachmentUploader. This removes an Android-only inconsistency: stream-chat-js sends audio this way, and iOS's client has mapped audio MIME types to .audio since 2022, with its SwiftUI composer following in 5.9.0 (#1565). Voice recordings are unaffected: they set audio_recording explicitly and the uploader keeps an already-set type.
• Follow-ons from that type change: the XML quoted attachment factory, view and its sizing branch handle audio instead of falling through to the unsupported path and image dimensions, the channel-list preview counts audio in its files bucket, deleting a message stops a playing audio file and not just a voice recording, and the samples' shared-files screens include it.
• All three mappers match audio on the MIME type's top-level type, startsWith("audio/"), so a subtype that merely mentions the word does not count. The backend does not derive the type from the MIME type, it consumes whatever the client declares, so this is the client's call. iOS resolves it the same way, by splitting on the slash and comparing the first component. Their existing image and video branches are left exactly as they are. AND-1452 tracks unifying the three, which also means tightening those looser branches.
• Reuse: PlaybackSlider is lifted out of VideoPlaybackControls and shared, as is the per-attachment playback state both audio players derive from AudioPlayerState. Sharing that state also gives voice recordings the player-reported duration as a fallback.

Notes

Compose only. The XML message list keeps rendering audio as a file card, unchanged, and its quoted attachments are fixed to keep doing the same after the type change, so AND-1360 stays open for the Views side. The ui-common player is generalised for both kits, so the XML player has nothing new to learn when it lands.

The typed-as-audio change is the one integrator-visible behaviour change. Code switching on AttachmentType.FILE to catch audio files needs to accept AttachmentType.AUDIO too. iOS shipped the same change as a Changed entry rather than a breaking one, which is why this is labelled pr:new-feature. Nothing is removed from the public API. Voice recordings keep their own UI and their playback is unchanged in normal use, but they now share the per-attachment playback state, so they pick up its edge-case handling: the player-reported duration as a fallback, a progress clamp, and a blank asset url counting as no source.

Two known rough edges, both inherited rather than introduced here, and both tracked in AND-1439:

• Tapping an audio row still opens the media preview, since that is currently the only way to open or save an audio attachment. The proper fix is the download action the design specifies, which no platform has shipped yet.
• Long pressing the seek bar does not open the message options, because the shared dragPointerInput consumes the gesture. The existing voice recording waveform behaves the same way.

The player shows elapsed time rather than total duration, since a regular audio attachment carries no duration and it is only known once the track loads. iOS loads it from the asset; worth revisiting if we want parity.

UI Changes

Before	After	Playing

Testing

• Snapshot coverage for the player idle, playing, uploading and multiple-attachment states, plus a mixed file and audio message rendered through the real FileAttachmentContent to FileAttachmentItem to AudioAttachmentItem path.
• AudioPlayerControllerTest: playback of a regular audio attachment, zero progress when no duration is known, the player-reported duration driving seeks, a seek held from both play and seekTo and applied once the duration arrives, and scrubbing leaving the track paused.
• MessageListControllerTests: deleting a message whose regular audio file is playing stops playback.
• The isPlayableAudio guard on every controller entry point, so a non-audio attachment is rejected by each.
• AttachmentUploaderTests: an audio mime type is typed audio, and an already-set type is preserved.
• AudioPlaybackTest pins the per-attachment playback state: no source for a missing or blank url, an attachment duration winning over the player's, a zero duration not counting as known, a stored seek surfacing on a track that is not loaded, and a progress the player could not compute being sanitised.
• DefaultQuotedAttachmentMessageFactoryTest covers the quoted attachment types the factory claims, audio included.
• Manually verified on an emulator: attaching an mp3 from the composer sends it as audio, and it renders, plays and reports its duration. The Before screenshot is that same message with develop's build installed over the top, so both columns show one message rather than two.