feat(payments): settle the direct rail through YooKassa

Replace Robokassa with YooKassa as the RUB direct-rail provider. The wallet
model is untouched: one `direct` segment, the same spend wall, the same
per-channel merchant shops (D42) and `shop` on the order (D44).

The two providers are not shaped alike, and that drives the change:

- Opening a purchase is now an outbound API call (`POST /v3/payments`,
  single-stage capture, redirect confirmation). The order id is both the
  `Idempotence-Key` and `metadata.order_id`, so a retried create cannot mint a
  second payment and a notification always resolves to its order.
- YooKassa does NOT sign notifications, so the body is never evidence: it only
  names a payment, which is re-read with `GET /v3/payments/{id}`, and only that
  answer is acted on. Two guards ride on it — the payment's metadata must name
  the order, and its `test` flag must match the shop's, so a test-shop payment
  can never credit real chips. The sender address is checked against YooKassa's
  published ranges first, which stops a forger turning each fabricated
  notification into an outbound call of ours.
- A notification lost for good would leave the money taken and the chips unowed,
  silently. The existing pending-order reaper now asks the provider about each
  order that reached its expiry age carrying a payment id, and credits the ones
  really paid — one request per order over its whole life, not polling.
- `payment.canceled` records a `failed` event, so a declined payment is finally
  surfaced to the customer as PAYMENTS.md §9 already specified.
- The admin refund moves the money through `POST /v3/refunds` before recording
  anything; a failed call records nothing, so the ledger cannot claim a refund
  that did not happen, and the recorded id is the provider's own.
- YooKassa has no cabinet-side generic receipt: «Чеки от ЮKassa» registers one
  only if the request carries it, so every payment and refund now sends an
  itemized `receipt` to the D36 confirmed email. The VAT rate code is a deploy
  variable; the settlement subject and method are constants.

Robokassa is retired, not deleted: the direct rail falls back to it when no
YooKassa shop is configured and no deployment sets its credentials, so reviving
it is a credentials change rather than a code change. Its variables are removed
from compose, .env.example, write-prod-env.sh and the three workflows, and
recorded in backend/internal/robokassa/README.md together with the cabinet
configuration and the revival steps. Ledger rows keep `provider = 'robokassa'`;
that literal is load-bearing for the idempotency index.

No migration and no wire change: `orders.provider_payment_id` already existed,
and the client is rail-agnostic.

Decisions D47-D51 (revising D41) and stage E12 are baked into the docs.

.gitea/workflows/ci.yaml

@@ -371,13 +371,14 @@ jobs:
           SMTP_RELAY_HOST: ${{ vars.SMTP_RELAY_HOST }}
           SMTP_RELAY_PORT: ${{ vars.SMTP_RELAY_PORT }}
           SMTP_RELAY_TLS: ${{ vars.SMTP_RELAY_TLS }}
-          # Direct-rail (Robokassa) sandbox intake on the contour: the test shop's merchant login +
-          # Password1/Password2. IsTest is forced to 1 below so the contour can never take real money
-          # (independent of the shop's own mode). Empty login leaves the direct rail off.
-          ROBOKASSA_MERCHANT_LOGIN: ${{ secrets.TEST_BACKEND_ROBOKASSA_MERCHANT_LOGIN }}
-          ROBOKASSA_PASSWORD1: ${{ secrets.TEST_BACKEND_ROBOKASSA_PASSWORD1 }}
-          ROBOKASSA_PASSWORD2: ${{ secrets.TEST_BACKEND_ROBOKASSA_PASSWORD2 }}
-          ROBOKASSA_TEST: "1"
+          # Direct-rail (YooKassa) intake on the contour: the credentials of a YooKassa TEST shop,
+          # which takes test cards and moves no real money. YOOKASSA_WEB_TEST is forced to 1 so the
+          # contour refuses to credit anything but a test payment, whatever credentials are set.
+          # Empty credentials leave the direct rail off.
+          YOOKASSA_WEB_SHOP_ID: ${{ secrets.TEST_BACKEND_YOOKASSA_WEB_SHOP_ID }}
+          YOOKASSA_WEB_SECRET_KEY: ${{ secrets.TEST_BACKEND_YOOKASSA_WEB_SECRET_KEY }}
+          YOOKASSA_WEB_TEST: "1"
+          YOOKASSA_VAT_CODE: ${{ vars.TEST_BACKEND_YOOKASSA_VAT_CODE }}
           SMTP_RELAY_FROM: ${{ vars.TEST_SMTP_RELAY_FROM }}
           # Operator alerts: backend admin emails (new feedback / complaints) + Grafana
           # infra alerts. Distinct senders + recipients; Grafana uses the relay's STARTTLS
@@ -576,15 +577,16 @@ jobs:
       - name: Probe the /pay/ callback route reaches the gateway
         run: |
           set -u
-          # /pay/robokassa/result must reach the gateway, not fall to the landing catch-all. An
-          # unsigned probe is rejected downstream, so the gateway answers a 4xx/5xx (never a 200 or
-          # a 404 landing.html), which proves the edge route is wired.
-          out="$(docker run --rm --network edge alpine:3.20 wget -S -q -O /dev/null http://scrabble/pay/robokassa/result 2>&1 || true)"
+          # /pay/yookassa/notify must reach the gateway, not fall to the landing catch-all. The probe
+          # is a bare GET from an address that is not one of YooKassa's senders, so it is rejected
+          # downstream and the gateway answers a 4xx/5xx (never a 200 or a 404 landing.html), which
+          # proves the edge route is wired.
+          out="$(docker run --rm --network edge alpine:3.20 wget -S -q -O /dev/null http://scrabble/pay/yookassa/notify 2>&1 || true)"
           echo "$out" | grep -E "HTTP/" || true
           if echo "$out" | grep -qE "HTTP/1\.1 (4|5)[0-9][0-9]"; then
             echo "ok: /pay/ reaches the gateway (non-landing response)"
           else
-            echo "FAIL: /pay/robokassa/result did not reach the gateway (landing catch-all?)"
+            echo "FAIL: /pay/yookassa/notify did not reach the gateway (landing catch-all?)"
             docker logs --tail 50 scrabble-gateway || true
             exit 1
           fi

.gitea/workflows/prod-deploy.yaml

@@ -99,14 +99,18 @@ jobs:
       GRAFANA_ADMIN_PASSWORD: ${{ secrets.PROD_GRAFANA_ADMIN_PASSWORD }}
       TELEGRAM_BOT_TOKEN: ${{ secrets.PROD_TELEGRAM_BOT_TOKEN }}
       GATEWAY_VK_APP_SECRET: ${{ secrets.GATEWAY_VK_APP_SECRET }}
-      # Robokassa direct-rail (backend BACKEND_ROBOKASSA_*): the prod shop login + the pass phrases
-      # that sign the launch request / verify the Result callback, and the test-mode flag — a var so
-      # go-live is a flag flip, not a secret redeploy ("1" runs test payments against the test
-      # passwords; empty/"0" is live). An empty login leaves the direct rail disabled.
-      ROBOKASSA_MERCHANT_LOGIN: ${{ secrets.PROD_BACKEND_ROBOKASSA_MERCHANT_LOGIN }}
-      ROBOKASSA_PASSWORD1: ${{ secrets.PROD_BACKEND_ROBOKASSA_PASSWORD1 }}
-      ROBOKASSA_PASSWORD2: ${{ secrets.PROD_BACKEND_ROBOKASSA_PASSWORD2 }}
-      ROBOKASSA_TEST: ${{ vars.PROD_BACKEND_ROBOKASSA_TEST }}
+      # YooKassa direct rail (backend BACKEND_YOOKASSA_*), one merchant shop per channel: the shop
+      # id + secret key, and a test-shop flag — a var, so pointing prod at a test shop is a flag
+      # flip rather than a secret rotation ("1" refuses to credit anything but a test payment;
+      # empty/"0" is live). Empty credentials leave that channel — or the whole rail — disabled.
+      # The VAT rate code on every receipt line is a var too, so a rate change needs no code change.
+      YOOKASSA_WEB_SHOP_ID: ${{ secrets.PROD_BACKEND_YOOKASSA_WEB_SHOP_ID }}
+      YOOKASSA_WEB_SECRET_KEY: ${{ secrets.PROD_BACKEND_YOOKASSA_WEB_SECRET_KEY }}
+      YOOKASSA_WEB_TEST: ${{ vars.PROD_BACKEND_YOOKASSA_WEB_TEST }}
+      YOOKASSA_ANDROID_SHOP_ID: ${{ secrets.PROD_BACKEND_YOOKASSA_ANDROID_SHOP_ID }}
+      YOOKASSA_ANDROID_SECRET_KEY: ${{ secrets.PROD_BACKEND_YOOKASSA_ANDROID_SECRET_KEY }}
+      YOOKASSA_ANDROID_TEST: ${{ vars.PROD_BACKEND_YOOKASSA_ANDROID_TEST }}
+      YOOKASSA_VAT_CODE: ${{ vars.PROD_BACKEND_YOOKASSA_VAT_CODE }}
       # VK ID web login: the "Web" app id (the gateway reuses it as GATEWAY_VK_ID_APP_ID at
       # runtime) + the app's protected key. Both shared across contours. The redirect URL is
       # derived from PUBLIC_BASE_URL in deploy/write-prod-env.sh.

.gitea/workflows/prod-rollback.yaml

@@ -61,12 +61,15 @@ jobs:
       # the SAME env.sh (email / VK login / Grafana alerts survive a rollback). TELEGRAM_MINIAPP_URL
       # and GRAFANA_ROOT_URL are derived from PUBLIC_BASE_URL in deploy/write-prod-env.sh.
       GATEWAY_VK_APP_SECRET: ${{ secrets.GATEWAY_VK_APP_SECRET }}
-      # Robokassa direct-rail: the rollback re-renders the same runtime env (write-prod-env.sh), so
+      # YooKassa direct rail: the rollback re-renders the same runtime env (write-prod-env.sh), so
       # it must carry the same credentials or the direct rail goes dark after a rollback.
-      ROBOKASSA_MERCHANT_LOGIN: ${{ secrets.PROD_BACKEND_ROBOKASSA_MERCHANT_LOGIN }}
-      ROBOKASSA_PASSWORD1: ${{ secrets.PROD_BACKEND_ROBOKASSA_PASSWORD1 }}
-      ROBOKASSA_PASSWORD2: ${{ secrets.PROD_BACKEND_ROBOKASSA_PASSWORD2 }}
-      ROBOKASSA_TEST: ${{ vars.PROD_BACKEND_ROBOKASSA_TEST }}
+      YOOKASSA_WEB_SHOP_ID: ${{ secrets.PROD_BACKEND_YOOKASSA_WEB_SHOP_ID }}
+      YOOKASSA_WEB_SECRET_KEY: ${{ secrets.PROD_BACKEND_YOOKASSA_WEB_SECRET_KEY }}
+      YOOKASSA_WEB_TEST: ${{ vars.PROD_BACKEND_YOOKASSA_WEB_TEST }}
+      YOOKASSA_ANDROID_SHOP_ID: ${{ secrets.PROD_BACKEND_YOOKASSA_ANDROID_SHOP_ID }}
+      YOOKASSA_ANDROID_SECRET_KEY: ${{ secrets.PROD_BACKEND_YOOKASSA_ANDROID_SECRET_KEY }}
+      YOOKASSA_ANDROID_TEST: ${{ vars.PROD_BACKEND_YOOKASSA_ANDROID_TEST }}
+      YOOKASSA_VAT_CODE: ${{ vars.PROD_BACKEND_YOOKASSA_VAT_CODE }}
       VITE_VK_APP_ID: ${{ vars.VITE_VK_APP_ID }}
       GATEWAY_VK_ID_CLIENT_SECRET: ${{ secrets.GATEWAY_VK_ID_CLIENT_SECRET }}
       GATEWAY_HONEYTOKEN: ${{ secrets.PROD_GATEWAY_HONEYTOKEN }}