Add block and media support to sendRichMessage

[FernandoWerneck-VibX]

What

Completes the Bot API 10.1 rich message sending surface. InputRichMessage now supports blocks and media in addition to html/markdown, and rich messages carrying uploaded files work across sendRichMessage, sendRichMessageDraft and editMessageText.

Changes

Input block models — new package model.request.richmessages.inputrichblock: the InputRichBlock interface, its 21 concrete blocks and InputRichBlockListItem. Plus InputRichMessageMedia, and InputMediaVoiceNote, which was missing and is required by InputRichBlockVoiceNote.

Type constants are reused from RichBlockType rather than duplicated, and blocks reference the existing received types where the API specifies them (RichText, RichBlockCaption, RichBlockTableCell, Location).

Serialization — RichBlock and RichText implementations declare their type discriminator as a computed property, which Gson does not serialize, and the registered adapters were JsonDeserializer only. RichTextTypeAdapter and RichBlockTypeAdapter now also implement JsonSerializer, and a new InputRichBlockSerializer covers the input hierarchy. Each delegates to the concrete runtime type and adds the discriminator back:

context.serialize(src, src.javaClass).asJsonObject.apply { addProperty("type", src.type) }

This does not recurse — the adapter is registered against the interface, while src.javaClass resolves to the concrete class's reflective adapter. RichText keeps the two special cases that mirror how it is parsed: RichTextPlain serializes as a bare string, RichTextArray as an array.

Multipart — SendRichMessage inherits isMultipart() == false from AbstractSendRequest, so blocks holding uploads had no plumbing. RichMessageAttachments walks media and blocks, descending into list, blockquote, collage, slideshow and details, and collects the attach:// mapping from each InputMedia.

It runs from isMultipart()/getParameters(), both of which TelegramBotClient reads at send time, and rescans on every call, dropping the parts left over from the previous scan. Unlike SendMediaGroup, which collects in its constructor, this means a rich message populated after the request was built is still uploaded, replacing a block also removes its stale part, and re-sending a request picks up media added in between.

Where the API forbids uploads, the request stays non-multipart and fails fast instead of building a payload Telegram would reject:

• sendRichMessageDraft — "Direct upload of new files isn't supported."
• editMessageText targeting an inline message — "Direct upload of new files isn't supported when an inline message is edited."

editMessageText — already accepted an InputRichMessage; it now collects attachments the same way.

Kotlin DSL — sendRichMessage and sendRichMessageDraft extensions, following SendMessageExtension.kt.

ModelTest — added prefab InputMedia values. EqualsVerifier cannot instantiate InputMedia because of its final self-typed thisAsT field, so every new model holding one failed.

Testing

17 unit tests in RichMessageRequestTest covering the discriminator of every block type, snake_case field names, rich text serialization, nested blocks, and attachment collection — nested, message-level, post-construction mutation, block replacement, the non-multipart case, and both upload-rejection paths.

./gradlew clean check -PprTest passes on JDK 11.