Keep the playback playlist in step with the chat and the profile

[FrayxRulez]

Second of three. #3379 is merged, so this is on develop; #3381 sits on top.

An open playlist was a snapshot of the moment playback started. Audio arriving in the chat never
appeared in it, and a message deleted while playing carried on to the end of the track.

Chat playlists

PlaybackService subscribes to the playing session's aggregator — the per-session one, not the
static instance the album cover file tokens go through — for UpdateNewMessage,
UpdateDeleteMessages and UpdateMessageContent, and drops the subscription with the
playlist.

A new message is only added once the newest end has been reached. Before that there are
messages between the playlist and the new one, and Extending the cursor over them would move
it past the gap and lose them for good. CanAddNewest is what gates it, and note it depends on
the playlist rather than on the direction: the newest message is the start of an audio playlist
and the end of a voice note one.

Accepts deliberately only compares topics when the playlist has one. A null topic means the
whole chat, and comparing anyway would reject everything, since in a forum every message carries
a topic and AreTheSame(null, x) is false.

UpdateMessageContent replaces the item rather than patching it, because everything an item
exposes — file, duration, title, cover — is read off the content when it is built. A content the
playlist does not play, which is what a voice note becomes when it expires, takes the item out
instead, and if it was playing that stops it, for the same reason a deletion does. When the
replaced item is the playing one, _currentItem is assigned directly rather than through the
property: the setter resets position and raises SourceChanged, and the player keeps streaming
the file it already opened — only what is displayed for it can have changed.

UpdateMessageSendSucceeded is deliberately not handled. A message added while it is still being
sent keeps the id it was added with, and that id is only ever compared against a later deletion
of the same message.

Deleting the playing message skips to the next one. That is a privacy matter, not tidiness —
whoever sent it took it back, so it should stop. FromCache and non-permanent deletions are
ignored, following GalleryWindow.

Profile audio

There is no server update for it, and the only changes are local ones made from PlaybackPopup,
so the popup reports them through ProfileAudioAdded / ProfileAudioRemoved — following the
precedent already set by MoveTo for drag-reorder. Removing an audio from your own profile is
not somebody taking a message back, so one playing when it leaves the list plays on.

Both adjust the source cursor by one, because profile paging is positional: inserting at the
front shifts everything after it down, and without moving the cursor the next page repeats or
skips an item.

Incidental

• PlaybackPreviousState now carries the source, so a music playlist interrupted by a voice note
  can still grow once it comes back. Without it the restore left _source null and paging was
  dead for the rest of the session.
• AudioWithOwner.Value keeps the Audio it copied its fields from, and PlaybackItem.Track
  exposes it, so an item can be moved into a profile playlist. Track rather than Audio
  because PlaybackItemProfileAudio.Audio already exists and is an AudioWithOwner.
• The service methods are named ProfileAudioAdded / ProfileAudioRemoved rather than after the
  td_api requests they follow, which would have shadowed AddProfileAudio / RemoveProfileAudio
  at the call site.

Testing

Builds clean. Not exercised at runtime.

🤖 Generated with Claude Code