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.

backend/internal/server/server.go

@@ -36,6 +36,7 @@ import (
 	"scrabble/backend/internal/session"
 	"scrabble/backend/internal/social"
 	"scrabble/backend/internal/telemetry"
+	"scrabble/backend/internal/yookassa"
 )
 
 // shutdownTimeout bounds how long Run waits for in-flight requests to finish
@@ -115,8 +116,18 @@ type Deps struct {
 	// Renderer is the image-render sidecar client for the PNG export artifact. A
 	// nil Renderer makes the PNG download answer 404 (the GCG artifact still works).
 	Renderer *render.Client
-	// Robokassa configures the direct-rail (RUB) provider — one merchant shop per channel; an empty
-	// set leaves the order and Result-callback endpoints unregistered.
+	// YooKassa configures the direct-rail (RUB) provider — one merchant shop per channel; an empty
+	// set leaves the order and notification endpoints unregistered and falls the direct rail back to
+	// Robokassa.
+	YooKassa yookassa.Shops
+	// YooKassaVatCode is the VAT rate code stamped on every fiscal receipt line (54-ФЗ tag 1199).
+	YooKassaVatCode int
+	// PublicBaseURL is the canonical https origin the payment return URL is built from. It is
+	// required whenever YooKassa is configured.
+	PublicBaseURL string
+	// Robokassa configures the retired direct-rail provider — one merchant shop per channel. No
+	// deployment sets it, so the set is empty and the direct rail resolves to YooKassa; it stays
+	// wired so restoring the rail is a credentials change (backend/internal/robokassa/README.md).
 	Robokassa robokassa.Shops
 }
 
@@ -146,6 +157,9 @@ type Server struct {
 	ads         *ads.Service
 	payments    *payments.Service
 	gamelimits  *gamelimits.Service
+	yookassa    yookassa.Shops
+	vatCode     int
+	publicURL   string
 	robokassa   robokassa.Shops
 	notifier    notify.Publisher
 	console     *adminconsole.Renderer
@@ -201,6 +215,9 @@ func New(addr string, deps Deps) *Server {
 		ads:           deps.Ads,
 		payments:      deps.Payments,
 		gamelimits:    deps.GameLimits,
+		yookassa:      deps.YooKassa,
+		vatCode:       deps.YooKassaVatCode,
+		publicURL:     deps.PublicBaseURL,
 		robokassa:     deps.Robokassa,
 		notifier:      notifier,
 		renderer:      deps.Renderer,