feat(payments): Telegram Stars payment rail

Accept real money via Telegram Stars (XTR) — the third intake rail
alongside Robokassa (direct) and VK Votes.

Only the bot reaches Telegram, so the rail funnels through the reverse
mTLS bot-link:
- the gateway mints the invoice on a CreateInvoice command (the bot
  calls createInvoiceLink, XTR; the link goes to WebApp.openInvoice);
- the bot gates each pre_checkout_query via a ValidatePreCheckout unary
  (the order must exist, be still creditable and not already paid — the
  reusable-invoice double-pay guard; the decline reason is localised to
  the order account's language);
- a completed successful_payment is queued in a durable pure-Go SQLite
  outbox and forwarded via a ForwardPayment unary, credited once
  (idempotent on telegram_payment_charge_id, honours an expired order),
  re-driven on restart and every 30s.

The rail is wired by TELEGRAM_STARS_OUTBOX_DIR (default /data) but stays
inert until a chip pack carries an XTR price, so seeding a Stars price in
the admin is the go-live.

Tests: backend integration (order->forward->credit once, duplicate,
pre_checkout gate) + bot outbox unit (idempotent, restart re-drive) +
executor createInvoice. Docs: PAYMENTS(+ru) §9, ARCHITECTURE, the
platform/telegram README, PLAN.

docs/ARCHITECTURE.md

@@ -971,7 +971,13 @@ the console; the backend calls them on the **gateway's bot-link relay**, which f
 to the bot and **awaits its delivery ack** (so the console still reports delivered/not). Beyond
 messages the same bot-link carries a **chat-gate control path** — a `ChatGate` command sets a user's
 write access in the moderated discussion chat and the bot's unary `ResolveChatEligibility` resolves a
-joiner's eligibility (neither renders a message; see *Moderated discussion chat* below). An optional
+joiner's eligibility (neither renders a message; see *Moderated discussion chat* below). It also
+carries the **Telegram Stars payment path** (§payments): a `CreateInvoice` command has the bot mint a
+`createInvoiceLink` (XTR) and return it in the Ack; the bot's unary `ValidatePreCheckout` gates a
+`pre_checkout_query` against the intake (declining an already-paid reusable invoice before the
+charge); and its unary `ForwardPayment` delivers a completed `successful_payment` — durably queued in
+a bot-side **SQLite outbox** (`platform/telegram/internal/outbox`, re-driven on restart) — which the
+gateway proxies to the backend intake, credited once (idempotent on `telegram_payment_charge_id`). An optional
 **standalone promo bot** runs in the bot container (`TELEGRAM_PROMO_BOT_TOKEN`): a second bot
 answering `/start` with a URL button into the **main** bot's Mini App (`?startapp`, since a `web_app`
 button would sign initData with the promo token); it is self-contained — no bot-link, no gateway.