PR1: feat(telegram): register bot command menu with setMyCommands

[rvalitov]

Fixes #136

🔢 Merge order

PR 1 of 4 — please merge this one FIRST.

This PR and the three that follow are a stack against main. GitHub requires a
PR's base branch to exist in the target repository, and these branches live in
a fork, so all four target main directly. The diffs will therefore look like
they overlap: PR 2's diff also contains PR 1's commits, PR 3's contains 1–2,
and so on. This resolves itself automatically as each one merges — no rebasing
is needed. Merging out of order will surface unrelated commits in the diff.

Related PR list:

1. PR1: feat(telegram): register bot command menu with setMyCommands #140
2. PR2: feat(telegram): keyboard primitives and update-parser rewrite #141
3. PR3: feat(telegram): interactive inline-keyboard menus #142
4. PR4: feat(telegram): traffic history, analytics and an informative periodic report #143

---

feat(telegram): register the bot command menu with setMyCommands

The problem

The bot has 27 commands, but nothing tells a user they exist. The client-side /
menu button shows an empty list, so the only way to discover a command is to
already know it — or to read /mp_help, which itself has to be known.

That is a poor fit for the public self-service tier in particular, where the
whole point is that an end user with a secret label can check their quota
without an admin walking them through it.

What this does

Registers command lists with Telegram via setMyCommands, scoped so each role
sees only what it may run:

Scope	Contents
Default (everyone)	TG_CMDS_PUBLIC — /start, /my_status, /redeem, /voucher, /support
Root admin chat + each superadmin in admins.conf	TG_CMDS_SUPERADMIN — the admin plane plus /mp_remove, /mp_restart, /mp_update, /mp_lockdown
Each reseller in admins.conf	TG_CMDS_ADMIN — the admin plane, minus the superadmin-only four

The scope mirrors the gates _process_cmd already applies, so the menu never
advertises something a role cannot actually run.

Three tables (TG_CMDS_PUBLIC, TG_CMDS_ADMIN, TG_CMDS_SUPERADMIN) are the
single source of truth. The bot daemon does not duplicate them — it re-runs
mtproxymax telegram sync-commands on boot instead.

When it re-syncs

• On bot service start (the daemon backgrounds a sync-commands before the poll loop)
• When an admin is granted a role (admin_add) or has one revoked (admin_remove) — revocation calls deleteMyCommands for that chat so a demoted admin stops seeing the admin plane
• Manually: mtproxymax telegram sync-commands
• At the end of telegram setup

Every call is best-effort. A Telegram outage must never abort setup or stall the
poll loop, so failures are logged and swallowed.

Defensive details

• Descriptions are sanitised before being embedded in JSON (control characters
  stripped, quotes and backslashes escaped). Telegram rejects the entire list
  if any single entry is malformed, so one stray character would blank the whole
  menu.
• _tg_api_post keeps the bot token out of the process list by writing the URL
  into a curl -K config file rather than passing it as an argument.

Testing

tests/test_telegram_commands.sh — 28 assertions, 0 failures.

It stubs curl to capture method | chat_id | commands into a TSV and asserts:
scoping per role, no duplicate commands across scopes, that the emitted bodies
are valid JSON, and that a network failure is survivable rather than fatal.

$ bash tests/test_telegram_commands.sh
28 tests, 0 failures

Files

• mtproxymax.sh — command tables, JSON rendering, sync/clear, CLI sync-commands, wizard and boot hooks
• tests/test_telegram_commands.sh — new
• README.md — documents the / menu and telegram sync-commands