Adopt the generated Attachment for downstream message attachments - #6671

Goal

Adopt the generated Attachment for downstream message attachments.

Part of AND-1291

Implementation

• AttachmentRequestAdapter becomes NetworkAttachmentAdapter. The same generated model is both the
  request and the response body, and its fromJson used to throw, so it now parses as well as serializes.
  Renamed rather than kept as AttachmentAdapter because parser2.direct.AttachmentAdapter already exists
  for the WebSocket event path.
• Swap the attachments on DownstreamMessageDto and DownstreamDraftMessageDto to the generated model.
  UpstreamMessageDto and Attachment.toDto() keep the hand-written DTO, so it stays for now.
• Attachment.toDomain() reads file_size, image, mime_type and name back out of the collected
  custom data and removes them. The spec does not declare them while the wire sends them at the root, so
  without this an attachment loses its size, name and mime type and carries them under their wire names in
  extraData instead. An undeclared number arrives untyped, so file_size is a Double and needs the
  numeric conversion rather than a cast to Int.
• author_icon, color, footer, footer_icon, pretext, actions, fields and giphy are declared
  by the generated model but were not by the hand-written DTO, so they would stop reaching
  Attachment.extraData. They go to alsoKeepInExtraData, and away with AND-1398.
• ChatClient.warmUpReflection() also warms the generated model. It lists the classes whose
  KClass.members costs hundreds of milliseconds on first use, so leaving it stale means the first real
  parse pays that cost.

Notes

giphy is kept as the raw object rather than rebuilt from the typed field. Attachment.giphyInfo() in
ui-common reads gif urls out of extraData["giphy"], and keeping the wire object preserves the exact map
it already reads. The reference implementation re-emitted it through Images.toLegacyMap(), which can only
reproduce the seven variants and five inner keys the model declares; alsoKeepInExtraData did not exist
when that was written.

A partial giphy cannot arrive: giphy.Images is seven value-type structs of five value-type strings with
no omitempty, so an unfilled variant serializes as empty strings rather than being omitted.

Testing

• AttachmentParsingTest gains a generated-path region covering the undeclared root fields landing in
  custom, the declared keys the keep set holds, and the giphy object keeping the shape giphyInfo()
  reads. The existing DTO-path and direct-path tests are untouched.
• DomainMappingTest covers the recovery of the four undeclared fields, that they do not also linger in
  extraData, and the giphy map surviving the mapping.
• Device-probed on the wire: a /giphy message returned all seven variants with a usable original.url
  and actions retained, and an uploaded file kept its name, mimeType and fileSize through both the
  send response and a fresh channel query with no wire names left in extraData. Giphy rendering checked
  by hand in the sample app, since the risk here is a display regression rather than a parse failure.

Summary by CodeRabbit

• Bug Fixes
  • Improved attachment parsing and mapping for messages and drafts.
  • Attachment metadata such as file size, image URL, MIME type, and name is now correctly restored.
  • Preserved custom attachment data, including Giphy information, for reliable UI display.
  • Reduced initial delays when attachments are used for the first time.
• Tests
  • Added coverage for generated attachment parsing, metadata conversion, and custom data preservation.