Tier 2: implement useful Bot API methods (setChatPermissions, sender-chat ban, invite-link edit/revoke, Stars accounting)

[windkh]

Tier 2 — Useful methods, reachable via passthrough but worth a thin wrapper

From the V18 coverage analysis (#453). These work through the generic (chatId, content, options) passthrough but have awkward semantics; a dedicated type + a small ergonomics shim would make them first-class.

Method(s)	Bot API	Why	Ergonomics note
setChatPermissions	4.4	Completes the group-admin story alongside restrictChatMember.	Reuse the same flat-permissions migration shim as restrictChatMember.
banChatSenderChat, unbanChatSenderChat	5.7	Anti-spam staple — block/unblock channels posting in a group.	Works via passthrough; add a documented type.
editChatInviteLink, revokeChatInviteLink	5.1	Round out the invite-link lifecycle (createChatInviteLink already supported).	—
getStarTransactions, getMyStarBalance	7.5 / 9.1	Accounting/monitoring for bots taking Stars.	form-only signature → not cleanly reachable.
getUserProfilePhotos	≤3.0	Common "who is this user" lookup.	userId-first signature is awkward via passthrough.

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.