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/cmd/backend/main.go

@@ -335,7 +335,11 @@ func run(ctx context.Context, cfg config.Config, logger *zap.Logger) error {
 		Notifier:      hub,
 		ExportSignKey: cfg.ExportSignKey,
 		Renderer:      renderer,
-		Robokassa:     cfg.Robokassa,
+		YooKassa:      cfg.YooKassa,
+
+		YooKassaVatCode: cfg.YooKassaVatCode,
+		PublicBaseURL:   cfg.PublicBaseURL,
+		Robokassa:       cfg.Robokassa,
 	})
 	pushSrv := pushgrpc.NewServer(cfg.GRPCAddr, hub, logger)
 
@@ -345,8 +349,8 @@ func run(ctx context.Context, cfg config.Config, logger *zap.Logger) error {
 		zap.String("http_addr", cfg.HTTPAddr),
 		zap.String("grpc_addr", cfg.GRPCAddr))
 	// Sweep expired pending payment orders on a cadence (cosmetic hygiene; a late valid callback
-	// still credits). Runs until ctx is cancelled.
-	go runOrderReaper(ctx, paymentsSvc, logger)
+	// still credits), asking the provider about each one first. Runs until ctx is cancelled.
+	go runOrderReaper(ctx, paymentsSvc, srv, logger)
 	// Deliver pending payment_events to connected clients as an in-app wallet-refresh push (the
 	// credit already landed in the ledger; a return-focus poll is the client-side fallback).
 	go runPaymentDispatcher(ctx, paymentsSvc, hub, logger)
@@ -363,7 +367,12 @@ func run(ctx context.Context, cfg config.Config, logger *zap.Logger) error {
 // runOrderReaper periodically expires pending payment orders past their configured lifetime, until
 // ctx is cancelled. Expiry is cosmetic: a later valid provider callback still credits an expired
 // order.
-func runOrderReaper(ctx context.Context, p *payments.Service, log *zap.Logger) {
+//
+// Before writing an order off it asks the provider what really happened to it — the one status check
+// each order gets, and the safety net for a notification that was lost for good (YooKassa redelivers
+// for 24 hours, so only a permanently lost one reaches here). A rail with no such check contributes
+// nothing to this pass.
+func runOrderReaper(ctx context.Context, p *payments.Service, srv *server.Server, log *zap.Logger) {
 	t := time.NewTicker(5 * time.Minute)
 	defer t.Stop()
 	for {
@@ -371,6 +380,9 @@ func runOrderReaper(ctx context.Context, p *payments.Service, log *zap.Logger) {
 		case <-ctx.Done():
 			return
 		case <-t.C:
+			if n := srv.ReconcileYooKassaOrders(ctx); n > 0 {
+				log.Info("order reaper: credited orders confirmed by the provider", zap.Int("count", n))
+			}
 			if n, err := p.ExpireOrders(ctx); err != nil {
 				log.Warn("order reaper: sweep failed", zap.Error(err))
 			} else if n > 0 {