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/handlers_intake.go

@@ -15,20 +15,28 @@ import (
 	"scrabble/backend/internal/robokassa"
 )
 
-// Ledger/order provider tags per rail.
+// Ledger/order provider tags per rail. providerRobokassa is retired but never renamed or reused:
+// historical ledger rows carry it, and it is load-bearing for the (provider, provider_payment_id)
+// idempotency index.
 const (
-	providerRobokassa = "robokassa" // the direct (RUB) rail
+	providerYooKassa  = "yookassa"  // the direct (RUB) rail
+	providerRobokassa = "robokassa" // the retired direct (RUB) rail
 	providerVK        = "vk"        // the VK Votes rail
 	providerTelegram  = "telegram"  // the Telegram Stars (XTR) rail
 )
 
+// yookassaReturnPath is where YooKassa returns the customer's browser after the hosted payment page.
+// The credit never rides this redirect — it rides the server notification — so the page only closes
+// the payment window and drops the customer back into the live app.
+const yookassaReturnPath = "/pay/yookassa/return"
+
 // walletOrderRequest is the POST body of a chip-pack purchase: the pack to fund.
 type walletOrderRequest struct {
 	ProductID string `json:"product_id"`
 }
 
 // walletOrderResponse returns the created order id and the rail's launch details. RedirectURL is
-// the provider's hosted-payment URL for the direct rail (empty for VK/Telegram, which settle
+// the provider's hosted-payment page for the direct rail (empty for VK/Telegram, which settle
 // in-app). Rail names the settling rail so the gateway knows how to launch it; for the Telegram
 // Stars rail the gateway mints the invoice link from InvoiceTitle and InvoiceAmount (whole stars)
 // via the bot and returns it in RedirectURL.
@@ -41,7 +49,7 @@ type walletOrderResponse struct {
 }
 
 // handleWalletOrder opens a pending order to fund a chip pack and returns the rail's launch
-// details for the client: the Robokassa hosted-payment URL (direct), the order id for
+// details for the client: the provider's hosted-payment URL (direct), the order id for
 // VKWebAppShowOrderBox (VK), or the pack title and star amount the gateway mints into a Stars
 // invoice link (Telegram). It enforces the wallet gate and, on the direct rail, D36 (a purchase
 // requires a confirmed email anchor). No chips are credited here — only later, by the verified
@@ -84,13 +92,20 @@ func (s *Server) handleWalletOrder(c *gin.Context) {
 	}
 	switch cxt.Kind {
 	case payments.SourceDirect:
-		shop, ok := s.robokassa.Shop(cxt.Subtype)
-		if !ok {
+		// YooKassa settles the direct rail. Robokassa is retired and normally unconfigured, so it is
+		// only reached when YooKassa has no shop for this channel — which is what makes reviving the
+		// old rail a credentials change rather than a code change. The rail is resolved before any
+		// account-level gate, so an unconfigured rail still reads as unavailable rather than as
+		// something the customer could fix.
+		ykShop, onYooKassa := s.yookassa.Shop(cxt.Subtype)
+		rkShop, onRobokassa := s.robokassa.Shop(cxt.Subtype)
+		if !onYooKassa && !onRobokassa {
 			c.AbortWithStatusJSON(http.StatusNotImplemented, errorResponse{Error: errorBody{Code: "rail_unavailable", Message: "this payment method is not available"}})
 			return
 		}
-		// D36: a direct purchase requires a confirmed email anchor.
-		hasEmail, err := s.accounts.HasConfirmedEmail(ctx, uid)
+		// D36: a direct purchase requires a confirmed email anchor, which is also where the fiscal
+		// receipt is delivered.
+		email, hasEmail, err := s.accounts.ConfirmedEmail(ctx, uid)
 		if err != nil {
 			s.abortErr(c, err)
 			return
@@ -99,6 +114,10 @@ func (s *Server) handleWalletOrder(c *gin.Context) {
 			c.AbortWithStatusJSON(http.StatusForbidden, errorResponse{Error: errorBody{Code: "email_required", Message: "confirm your email before making a purchase"}})
 			return
 		}
+		if onYooKassa {
+			s.orderYooKassa(c, uid, cxt, present, productID, ykShop, email)
+			return
+		}
 		res, err := s.payments.CreateOrder(ctx, uid, cxt, present, productID, providerRobokassa)
 		if err != nil {
 			s.abortErr(c, err)
@@ -106,7 +125,7 @@ func (s *Server) handleWalletOrder(c *gin.Context) {
 		}
 		c.JSON(http.StatusOK, walletOrderResponse{
 			OrderID:     res.OrderID.String(),
-			RedirectURL: shop.PaymentURL(res.OrderID, res.Amount.Major(), res.Title),
+			RedirectURL: rkShop.PaymentURL(res.OrderID, res.Amount.Major(), res.Title),
 			Rail:        providerRobokassa,
 		})
 	case payments.SourceVK: