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.

docs/PAYMENTS.md

@@ -219,12 +219,21 @@ the amount, credits, marks `paid`. **Idempotency:** dedup by `(provider, provide
 valid callback is **always** honoured, even on an expired order (`expired` ≠ cancellation —
 the money is real, the chips are owed). The user sees only successful purchases.
 
-**TG bot outbox.** `successful_payment` reaches the bot only (Bot API, not the Mini App), and
-the bot host is weak and can lose connectivity, so the bot is a durable link. Store-and-
-forward on **SQLite** on the bot's disk: receive → store → ack the Telegram update → forward
-to payments (idempotent, dedup by `telegram_payment_charge_id`) → ack → mark `forwarded`.
-Retries with backoff; re-drives undelivered on restart. At-least-once delivery + idempotent
-intake = credited exactly once.
+**TG Stars.** Only the **bot** reaches Telegram, so the whole rail funnels through the reverse
+mTLS **bot-link** (bot ↔ gateway; the bot cannot dial the backend). The invoice is minted by the
+bot: on the order path the gateway sends a `CreateInvoice` command and the bot returns a
+`createInvoiceLink` (XTR) in its Ack, which the Mini App opens with `WebApp.openInvoice`. Before any
+star moves the bot answers `pre_checkout_query` via a bot→gateway `ValidatePreCheckout` unary
+(backed by the intake): approve only if the order exists, is still creditable and is **not already
+paid** — a Stars invoice link is reusable, so this gate is the one place a repeat payment is stopped
+before the charge; the decline reason is localised to the order account's language.
+
+`successful_payment` reaches the bot only (Bot API, not the Mini App), and the bot host is weak and
+can lose connectivity, so the bot is a durable link. Store-and-forward on **SQLite** on the bot's
+disk (`internal/outbox`): persist on receipt (idempotent on `telegram_payment_charge_id`) → forward
+over the bot-link (a `ForwardPayment` unary; the gateway proxies to the intake) → on a durable
+response, mark `forwarded`. Re-drives undelivered on restart and on a periodic tick. At-least-once
+delivery + idempotent intake (dedup by `telegram_payment_charge_id`) = credited exactly once.
 
 **Events.** The payments domain writes `payment_events` (succeeded / failed / refunded); a
 dispatcher fans out over channels — the live gRPC stream if the user is in-app, else the

docs/PAYMENTS_ru.md

@@ -220,12 +220,22 @@ provider_payment_id)`.
 Валидный колбэк исполняется **всегда**, даже на истёкшем заказе (`expired` ≠ отмена —
 деньги реальны, Фишки должны быть выданы). Пользователь видит только успешные покупки.
 
-**Outbox TG-бота.** `successful_payment` приходит только боту (Bot API, не Mini App), а
-хост бота слабый и может терять связь, поэтому бот — durable-звено. Store-and-forward на
-**SQLite** на диске бота: получил → сохранил → подтвердил апдейт Telegram → форвардит в
-платёжный домен (идемпотентно, дедуп по `telegram_payment_charge_id`) → ack → пометил
-`forwarded`. Ретраи с backoff; дореталивает недоставленное при рестарте. Доставка
-at-least-once + идемпотентный приём = начисление ровно один раз.
+**TG Stars.** До Telegram дотягивается только **бот**, поэтому весь рельс идёт через обратный
+mTLS **bot-link** (бот ↔ gateway; напрямую к бэкенду бот не ходит). Инвойс создаёт бот: на пути
+заказа gateway шлёт команду `CreateInvoice`, а бот возвращает `createInvoiceLink` (XTR) в Ack,
+который Mini App открывает через `WebApp.openInvoice`. До списания звёзд бот отвечает на
+`pre_checkout_query` через унарный вызов бот→gateway `ValidatePreCheckout` (за ним — приём): одобрить,
+только если заказ существует, ещё оплачиваем и **не оплачен ранее** — ссылка Stars-инвойса
+переиспользуема, так что этот гейт — единственное место, где повторная оплата отсекается **до**
+списания; текст отказа локализован в язык аккаунта заказа.
+
+**Outbox TG-бота.** `successful_payment` приходит только боту (Bot API, не Mini App), а хост бота
+слабый и может терять связь, поэтому бот — durable-звено. Store-and-forward на **SQLite** на диске
+бота (`internal/outbox`): сохранил при получении (идемпотентно по `telegram_payment_charge_id`) →
+форвардит по bot-link (унарный `ForwardPayment`; gateway проксирует в приём) → при durable-ответе
+пометил `forwarded`. Дореталивает недоставленное при рестарте и по периодическому тику. Доставка
+at-least-once + идемпотентный приём (дедуп по `telegram_payment_charge_id`) = начисление ровно один
+раз.
 
 **События.** Платёжный домен пишет `payment_events` (succeeded / failed / refunded);
 диспетчер рассылает по каналам — live gRPC-стрим, если пользователь в аппе, иначе