feat(telegram): Init bot commands on start

[mymmrac]

This PR adds a setup of Telegram bot commands, so that users will see list of available commands in the bot

[Leeaandrob]

@Zepan Initializes Telegram bot commands on startup so users see the command menu in the Telegram UI. Good DX improvement.

Recommendation: Merge. +65/-12, clean implementation that improves the Telegram user experience.

[nikolasdehor]

Clean implementation with smart rate-limit handling via slices.Equal — avoids unnecessary SetMyCommands calls since Telegram aggressively rate-limits that endpoint.

The lifecycle improvements are also welcome: proper StopWithContext, error logging for bh.Start(), and fixing the swallowed error in the /help handler.

One suggestion (non-blocking): Consider making initBotCommands non-fatal. If there's a transient network error at startup, logging a warning and continuing would be better than failing the entire channel initialization. The bot works fine without the command menu.

if err := c.initBotCommands(ctx); err != nil {
    logger.WarnCF("telegram", "Failed to init bot commands (non-fatal): %v", err)
}

Note: nice that you (the telego library author) are contributing directly — high confidence in the patterns. LGTM.

[nikolasdehor]

Clean implementation with smart rate-limit avoidance via slices.Equal. The lifecycle improvements (proper StopWithContext, error logging for bh.Start()) are also welcome.

One suggestion: consider making initBotCommands non-fatal. A transient network error at startup shouldn't prevent the entire channel from initializing — the bot works fine without the command menu:
```go
if err := c.initBotCommands(ctx); err != nil {
logger.WarnCF("telegram", "Failed to init bot commands (non-fatal): %v", err)
}
```

Also great that you're fixing the swallowed error in the /help handler (return c.commands.Help(...) instead of ignoring the return). LGTM.

[lukemilby]

@mymmrac can you add a screenshot of what the user will see

[mymmrac]

Looks like this:

[lukemilby]

Looks good.

[PixelTux]

Good implementation and nice code cleanup. LGTM.

[alexhoshina]

Please develop based on the refactor branch. The refactor branch is about to be merged, and PRs developed based on main before the merge will not be reviewed.

The refactor branch is scheduled to be merged during the daytime of February 28, 2026, Beijing Time (GMT+8), with the exact time yet to be determined. You may wait until after the merge to request a PR review Or complete the review before finishing the merge; I will review your PR as quickly as possible We have provided comprehensive migration documentation for the new channel system.

[yinwm]

thanks for the pr