Migrate the thread reply and pinned message responses to the generated MessageResponse - #6733

Goal

Parse the messages returned by the thread replies and pinned messages endpoints with the generated
MessageResponse.

Part of AND-1291

Implementation

• Point MessagesResponse.messages at the generated MessageResponse and map it with a new
  MessageResponse.toDomain(), alongside the existing DownstreamMessageDto mapper, which every other
  endpoint still uses.
• Vendor MessageResponse and the models only it needs: DraftResponse, ReminderResponseData and
  SharedLocationResponseData, each with its own mapper.
• MessageResponseAdapter collects the flattened custom data. Keys the generated model now declares
  (mml, poll_id, restricted_visibility, mentioned_group_ids, image_labels, draft) stay in
  extraData as well, as they were before.
• V1 moderation_details is not declared on the payload and arrives as custom data, so it is read from
  there into moderationDetails and removed from extraData.
• A null entry in mentioned_channel_members is skipped instead of throwing.

Testing

Mutation sweep over the new mappers: zero survivors.

MessageResponseParityTest parses every message fixture through both the hand-written DTO and the
generated model and requires the same Message, field by field. Where a fixture was leaner than the wire,
it only fills fields the backend always sends.

Device-probed a thread reply with a mention, a custom attachment, a quote, a reaction, a reminder and custom
data, and a pinned parent and a pinned static location. Every field matched getMessage, which still parses
the hand-written DTO. The differences were what the endpoints send: neither endpoint sends the message's
channel, and pinned messages come back without shared_location, thread_participants or poll. That last
one is the same on develop.

A second probe put unusual messages in a thread and in the pinned list: a soft-deleted reply, a link
preview, silent and shown-in-channel replies, an image attachment, a quote of a deleted message, a
translation, a giphy, a poll and an expiring pin. Both endpoints parsed them all, and each matched
getMessage apart from the endpoint differences above.

The generated model requires some fields the hand-written DTO did not, so a missing one would fail the whole
response. Every required field across the models these responses reach is a plain, always-sent tag on the
backend, including the placeholder user sent for a deleted author, which a new parity fixture covers.

Summary by CodeRabbit

• Improvements
  • Message data now better preserves details such as polls, reminders, shared locations, reactions, and quoted messages when received from the service.
  • Custom message fields and moderation details are handled more consistently.
  • Poll update times now reflect the latest available update.
• Bug Fixes
  • Improved handling of missing message collections and channel information to support more reliable message display.