#12978: fix(telegram): use real message_id for inline button callback reactions

## Summary Fixes Telegram inline button callback using the callback query ID instead of the real message ID, causing reactions to fail with `400: Bad Request: message to react not found`. Closes #12886 ## Changes - **`bot-handlers.ts`**: Added `reactionMessageId: String(callbackMessage.message_id)` to both callback query handler paths (model selection + generic callbacks), preserving `callback.id` as `messageIdOverride` for dedup - **`bot-message-context.ts`**: Added `reactionMessageId` to options type; populates `MessageSidFull` with the real message ID when set - **`bot-message.ts`** / **`bot-native-commands.ts`**: Updated options type to include `reactionMessageId` ## How It Works - `MessageSid` = `callback.id` (callback query ID) — used for message dedup, so distinct button presses are processed independently - `MessageSidFull` = `callbackMessage.message_id` (real Telegram message ID) — used for the `[message_id: ...]` hint shown to agents - Existing resolution (`MessageSidFull ?? MessageSid`) ensures agents see the real message ID for reactions ## Testing - Added test verifying `MessageSid` remains the callback query ID and `MessageSidFull` contains the real message ID - All 415 Telegram tests pass - Pre-existing dedup test continues to pass (callback IDs remain distinct for dedup) 🤖 Generated with Claude (AI-assisted) <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR fixes Telegram inline-button callback handling by keeping `MessageSid` as the callback query id (so each button press dedups independently) while additionally exposing the *real* Telegram `message_id` via `MessageSidFull` (used downstream for reactions and other message-id based features). Concretely, the callback_query handler now passes `reactionMessageId` derived from `callbackQuery.message.message_id`, and the Telegram message context builder wires that into `ctxPayload.MessageSidFull`. This fits the existing reply pipeline where downstream code already prefers `MessageSidFull ?? MessageSid` when it needs an actual provider message id (e.g., for reaction APIs), while still using `MessageSid` as the primary stable/dedup identifier. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk. - Changes are small, localized, and align with existing downstream expectations (`MessageSidFull ?? MessageSid`). A targeted test was added to validate the new behavior for callback_query flows, and the new option is threaded through relevant types without altering unrelated processing paths. - No files require special attention <!-- greptile_other_comments_section --> <!-- /greptile_comment -->