[Refactor] Unify Telegram elicitation prompt retirement

[roomote-roomote]

​Created by Roomote. View the task or mention @roomote-roomote for follow-up asks.

What changed

• Consolidated Telegram elicitation confirmation text replacement, button removal, and managed-footer state updates into the existing lock-aware retirement operation.
• Kept stale prompt retirement as the button-only form of the same operation and retained fallback confirmation posting when an in-place edit is unavailable.
• Updated focused API and SDK coverage for single-mutation ownership, persisted confirmation text, Markdown delivery, stale retirement, and fallback behavior.

Why this change was made

Answer confirmation previously retired the keyboard through the SDK and then edited the same Telegram message again in the API handler. Splitting one lifecycle transition across layers created duplicate provider calls and left persisted footer text out of sync with the rendered confirmation.

Impact

Telegram answers now retire their prompt with one owned message mutation, and later managed-footer refreshes cannot restore the old prompt text or controls. Submission semantics and best-effort fallback delivery are unchanged.

[roomote-community]

1 issue outstanding. See task

• packages/sdk/src/server/lib/communication-request-user-input.ts:300 Failed replacement edits leave the original prompt's inline keyboard active.

_{Reviewed b117fa3}

[roomote-community]

If editMessageText fails, the record has already been rewritten without buttons, so this returns false and confirmAnswer posts a fallback confirmation without making another mutation to the original prompt. Its inline keyboard therefore remains visible until a later footer refresh (and can be clicked in the meantime). Previously the separate editMessageReplyMarkup call retired the keyboard before the text edit. On this failure path, also clear the reply markup best-effort, or otherwise preserve the old two-step cleanup behavior.