feat(telegram): add plugin-owned callback actions

[prvk]

Summary

• adds a platform_callback plugin hook for authorized Telegram callbacks that are not claimed by built-in handlers
• lets cron jobs attach bounded inline keyboards through repeatable --button options
• carries keyboards through live gateway and standalone Telegram delivery

Safety

• transport objects stay inside the Telegram adapter; plugins receive normalized scalar context
• existing Telegram callback authorization runs before plugin dispatch
• callback answers and replacement keyboards are strictly bounded
• existing jobs and sends remain byte-compatible when no buttons are configured

Verification

• 357 focused gateway, cron, CLI, and standalone-send tests pass
• Ruff checks pass for all changed files

[alt-glitch]

This was generated by AI during triage.

Related to #21469 / #21471: this PR adds a post-built-in callback hook plus cron-delivery buttons, while #21471's pre-callback hook intercepts before built-in routing. Same extension area, different ownership semantics; maintainers can evaluate them together.

[teknium1]

Thanks for the focused post-built-in callback design and for covering both live and standalone delivery paths.

Problems

• tools/send_message_tool.py:1353 attaches markup only when the media item is the final input entry. If that entry is missing or fails after an earlier media send succeeds, delivery succeeds without any keyboard.
• cron/jobs.py:1053 accepts built-in callback prefixes. Telegram claims mp:, gt:, ea:, sc:, cl:, and update_prompt: before the new hook (plugins/platforms/telegram/adapter.py:5637-5945 on current main), so those buttons are not plugin-owned.
• --button has no supported clear operation despite cron edit advertising replacement; an empty button list is invalid.
• The public hook reference still says only two hook return values affect behavior (website/docs/user-guide/features/hooks.md:374).

Suggested changes

• Deliver markup on the final successful message/media and test missing-final-media behavior.
• Reserve or reject built-in callback namespaces, add a clear-buttons path, and document the new hook contract.

Automated hermes-sweeper review.

[teknium1]

This selects the final input attachment rather than the final successfully delivered attachment. If this final file is absent (or its send fails) after an earlier media send succeeds, the method returns success but no message has reply_markup. Attach the keyboard to the final successful send and cover that fallback.

[teknium1]

Please reject or reserve Telegram's built-in callback namespaces here. Values such as ea:, sc:, cl:, gt:, mp:, and update_prompt: are consumed before the post-built-in plugin hook, contradicting the CLI contract that this callback data is handled by platform_callback.

[acherley]

Thanks — this overlaps a generic callback/delivery surface I was preparing for an external plugin, so I’m avoiding a competing PR while this and #59159 are open.

A concrete external-plugin consumer needs the following combination:

1. Claim only its own callback-data prefix, while preserving built-in callback families and normal fallback behavior.
2. Attach an inline keyboard to a photo delivery (a human-in-the-loop prompt may be image-first rather than text-first).
3. Receive a bounded post-send hook so it can bind the returned Telegram message ID and later remove stale markup.
4. Preprocess a per-target cron delivery before media extraction without being able to override core-owned route metadata (job_id, thread_id, or direct_messages_topic_id).

Does the proposed cron button syntax remain attached when the result is primarily a MEDIA: image, and is a platform plugin expected to claim callbacks through platform_callback or through the PTB-handler registration proposed in #59159?

I’m happy to adapt the external consumer to whichever single API maintainers prefer; the goal is to converge rather than add another overlapping callback hook.