feat(payments): trusted platform signal on the session

Record the execution platform (kind vk|telegram|direct + device subtype
ios|android|web) on each session, captured at creation and carried
gateway->backend as a trusted X-Platform header, so the upcoming
store-compliance gate has an unforgeable execution context.

- backend.sessions gains nullable platform_kind/platform_subtype columns
  (migration 00011, CHECK-constrained, jet regenerated); session.Platform
  captures them at mint, resolve returns them, middleware exposes platform(c).
  kind is derived from the establish endpoint, never a client field; the
  account-merge session mint inherits the caller's platform.
- gateway derives the platform (VK subtype from the signed vk_platform via
  vkauth, Telegram/direct best-effort from the client) and injects X-Platform
  on every authenticated backend call through the request context.
- ui submits a best-effort device subtype on the telegram/guest/email login
  requests (new FBS subtype field); VK is server-derived from the signed params.
- an unattributed session is untrusted (view-only); VK/TG self-heal on the next
  cold-start re-mint, direct/email on re-login.

Signal plumbing only, no user-visible change; X-Platform is inert until the
gate consumes it.

docs/ARCHITECTURE.md

@@ -130,8 +130,8 @@ dropped). Horizontal scaling is explicit future work.
   solver version, so it cannot drift from the running backend. The **move journal, history
   and GCG are unaffected** (they stay decoded concrete characters, §9.1).
 - **gateway ↔ backend (sync)**: plain HTTP REST/JSON. The gateway injects
-  `X-User-ID` for authenticated requests; `backend` never re-derives identity
-  from the body. Because every sync call targets the one backend host, the
+  `X-User-ID` (and the session's trusted `X-Platform`, §3) for authenticated
+  requests; `backend` never re-derives identity or platform from the body. Because every sync call targets the one backend host, the
   gateway's REST client widens its keep-alive pool well past the stdlib default
   of 2 idle connections per host; otherwise the per-request connection churn
   exhausts ephemeral ports and burns gateway CPU under load (see
@@ -199,6 +199,21 @@ arrive from a platform rather than completing a mandatory registration).
   until explicitly revoked (`status` → `revoked`). A revoke can target one token or,
   on an account merge (§4), **every** session of the retired account
   (`RevokeAllForAccount`, which also evicts them from the warm cache).
+- **Trusted execution platform.** Each session also records a `platform` — a `kind`
+  (`vk`/`telegram`/`direct`) plus a device `subtype` (`ios`/`android`/`web`) — captured
+  at creation, so a store-compliance gate has an unforgeable execution context
+  (`docs/PAYMENTS.md` §8). `kind` is derived server-side from the validated establish
+  path (the VK launch, the Telegram initData, or a web-native session), **never a client
+  field**; the `subtype` is trusted only for VK (it rides inside the signed `vk_platform`
+  parameter) and is client-reported best-effort for telegram/direct. VK and Telegram
+  re-mint (and so re-validate and re-capture) on every cold start; a direct session
+  captures it once. The gateway injects the resolved platform as **`X-Platform`**
+  (`<kind>/<subtype>`) alongside `X-User-ID`, sourced from the session and never the
+  request body; an absent or unrecorded platform — a session predating the feature, or
+  one the gateway could not attribute — is **untrusted**, treated as view-only (no
+  spends). Consistent with the revoke-only model, platform freshness carries no separate
+  TTL; a stale untrusted session recovers on its next VK/TG cold-start re-mint, or (for a
+  reused direct/email session) on re-login.
 - **Guest** = ephemeral web session (no platform, no email). A guest is backed by
   a durable `accounts` row flagged `is_guest` and carrying **no identity** — the
   row is a technical necessity (the `sessions` and `game_players` foreign keys
@@ -1150,7 +1165,7 @@ link — misses the event; while an add-email confirmation is pending the client
 | Public rate limiting / anti-abuse | gateway (per-IP public/email/admin classes, per-user authenticated class; a request body cap of `GATEWAY_MAX_BODY_BYTES`; rejections are metered, summarised to the backend and surfaced in the admin console with a conservative reversible auto-flag — §11). In prod a **temporary IP ban** (`GATEWAY_ABUSE_BAN_ENABLED`) blocks an IP that sustains rejections or trips a **honeypot** decoy path / **honeytoken**, refused with 429 before any work; operators lift bans from the console. Off in the shared-NAT test contour, where the client IP is not real (§11) |
 | Telegram initData validation (bot-token HMAC) | the Telegram **validator**; the gateway delegates it over gRPC, so the bot token (the HMAC secret) lives only in the validator and the bot, never in the gateway. The validator also **rejects a bot principal** (the signed `is_bot` flag) before any account is provisioned |
 | Session minting; email-code / guest validation | gateway (with backend) |
-| Session → `user_id` resolution, `X-User-ID` injection | gateway |
+| Session → `user_id` + trusted platform resolution, `X-User-ID` / `X-Platform` injection | gateway (platform sourced from the session, never the request body — §3) |
 | Authorisation, ownership, state transitions | backend (`X-User-ID` is the sole identity input) |
 | Manual account block (suspension) | backend: a per-request gate refuses a blocked account on every `/api/v1/user/*` route except the block-status probe with **403 `account_blocked`**; the operator blocks/unblocks from the admin console (§11) |
 | User feedback gate | backend rejects a guest or a `feedback_banned` account from submitting; the **gateway** also rejects a guest's `feedback.submit` (the `Op.NonGuest` flag + `is_guest` from session resolve) with **`guest_forbidden`** before any backend call; attachments are served `nosniff` with a download disposition for non-images (§15) |