Tier 1: implement critical Bot API methods (setMyCommands, createInvoiceLink, refundStarPayment, batch message ops)

[windkh]

Tier 1 — Critical / high-value Bot API methods to add first-class support

From the V18 coverage analysis (#453). These are useful or critical AND not reachable via the sender node's generic (chatId, content, options) passthrough, so they need dedicated handling.

Method(s)	Bot API	Why critical/useful	Why passthrough can't reach it
setMyCommands, getMyCommands, deleteMyCommands	4.7 / 5.3	Register the bot's command menu (scopes/languages). Most-requested gap; natural extension of the command node.	First arg is commands, no chatId.
createInvoiceLink	6.1	Modern payments — shareable pay link instead of an in-chat invoice. Pairs with existing sendInvoice.	6 positional args, no chatId.
refundStarPayment	7.4	Compliance-critical for bots accepting Telegram Stars — without it the bot can't honor refund requests.	(userId, chargeId) semantics.
forwardMessages, copyMessages, deleteMessages	7.0	Batch moderation/cleanup (bulk delete spam, bulk forward).	forward/copyMessages are 4-arg.

Notes

• Once the callApi escape hatch lands, all of these are technically callable; this issue is about first-class types + ergonomics + examples for the common ones.
• setMyCommands is the clear priority — consider wiring it through the command node config.

Related: #453, #448.

[windkh]

On hold pending #501 — do not implement this against the v1 API surface.

node-telegram-bot-api@2.0.0 is released and describes itself as "a from-scratch redesign with no backward compatibility" with the v1 TelegramBot surface. Among other things it replaces positional arguments with params objects under a uniform bot.api.* namespace, and covers Bot API 10.2 natively.

This issue was written on 2026-06-17 against v1. Two things about it are now uncertain:

• Whether the work is still needed. Methods listed here may already be reachable through v2's bot.api.* surface, in which case the remaining work is exposing them in the nodes, not implementing them.
• Whether the tiering still holds. v2 changes the effort profile, so the split across Tier 1–4 may need re-cutting rather than the tiers being worked in order.

Anything implemented against v1 in the meantime would very likely be thrown away in the port.

Action: this issue is re-checked as part of #501, after the breaking-change analysis it requires. It stays open until then — no assumption either way. Kept as-is on purpose: it records what users asked for, and that need survives the library change even if the implementation does not.