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/PAYMENTS.md

@@ -180,20 +180,23 @@ an archive, so history/receipts/tax are independent of later catalog edits.
 The gate (§4) needs a **trusted, unforgeable** platform context on the server. The client is
 never the source of truth.
 
-- The platform is a **property of the session**, re-confirmed by a fresh signature on **every
-  cold start** — VK launch-params `sign` / TG `initData` (validator already exists at
-  `platform/telegram/internal/initdata`). VK/TG wrappers resend the signature on every open,
-  so this is not a one-time login.
-- `direct` is established by the fact of a web/native session's creation (no external
-  signer, and none needed — reaching vk/tg segments in a direct context still requires a
-  real attachment, §6).
+- The platform is a **property of the session**, captured when the session is created. VK and
+  Telegram wrappers re-mint (and so re-validate the launch signature — VK launch-params `sign`
+  / Telegram `initData`) on **every cold start**, so their platform is re-confirmed each launch;
+  a `direct` session captures it once, established by the fact of a web/native session's creation
+  (no external signer, and none needed — reaching vk/tg segments in a direct context still
+  requires a real attachment, §6).
 - The platform carries **kind** (`vk`/`telegram`/`direct`) **plus subtype**
-  (`ios`/`android`/`web`) — the subtype is mandatory (VK iOS is frozen).
-- The gateway resolves the session and passes `platform` to the backend (alongside the
-  existing `X-User-ID`).
-- **Fail-closed:** an untrusted/unconfirmed platform (a VK/TG session without a valid
-  cold-start signature; an old session with no recorded platform) denies spends/purchases
-  and applying any foreign origin — view only.
+  (`ios`/`android`/`web`). `kind` is always trusted — the server derives it from the validated
+  launch, never a client field. The **subtype is trusted only for VK**: it rides inside the
+  signed launch parameters, which is what makes the **VK iOS freeze** enforceable; for Telegram
+  and direct the subtype is client-reported and best-effort, so the gate never keys off it.
+- The gateway resolves the session and passes `platform` to the backend (alongside the existing
+  `X-User-ID`), sourced from the session — never the client request body.
+- **Fail-closed:** an untrusted platform — a session with no recorded platform, one predating
+  this feature or one the gateway could not attribute — denies spends/purchases and applying any
+  foreign origin (view only). A VK/TG session recovers on its next cold-start re-mint; a reused
+  direct/email session on re-login.
 
 ## 9. Payment intake