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/payments/service_intake.go

@@ -64,6 +64,83 @@ func directShop(cxt Context) string {
 	return ""
 }
 
+// AttachProviderPayment records the provider's own payment identifier on a pending order, right
+// after the provider mints it and before the customer has paid. Two later paths depend on it: the
+// reconcile sweep, which asks the provider what became of an order no callback ever confirmed, and a
+// refund, which must address the original payment. It does not credit anything and does not change
+// the order status.
+func (s *Service) AttachProviderPayment(ctx context.Context, orderID uuid.UUID, provider, providerPaymentID string) error {
+	return s.store.attachProviderPayment(ctx, orderID, provider, providerPaymentID, s.clock())
+}
+
+// OrderRef identifies a stored order to a provider: which rail settles it, that rail's own payment
+// id, the merchant shop channel it was issued through, and the amount and account it belongs to. It
+// is what the reconcile sweep and the refund path need without giving them the whole order.
+type OrderRef struct {
+	OrderID   uuid.UUID
+	AccountID uuid.UUID
+	Provider  string
+	PaymentID string
+	Shop      string
+	Amount    Money
+	Status    string
+}
+
+// orderRef projects a stored order onto an OrderRef.
+func orderRef(o orderRow) (OrderRef, error) {
+	amount, err := MoneyFromMinor(o.expectedAmount, Currency(o.currency))
+	if err != nil {
+		return OrderRef{}, err
+	}
+	return OrderRef{
+		OrderID:   o.orderID,
+		AccountID: o.accountID,
+		Provider:  o.provider,
+		PaymentID: o.paymentID,
+		Shop:      o.shop,
+		Amount:    amount,
+		Status:    o.status,
+	}, nil
+}
+
+// OrderProviderRef reads how an order reaches its provider — the rail, that rail's payment id and
+// the shop it was issued through. The refund path uses it to call the right merchant account.
+func (s *Service) OrderProviderRef(ctx context.Context, orderID uuid.UUID) (OrderRef, error) {
+	o, err := s.store.orderByID(ctx, orderID)
+	if err != nil {
+		return OrderRef{}, err
+	}
+	return orderRef(o)
+}
+
+// reconcileBatch bounds one reconcile sweep, so a backlog cannot turn a periodic tick into a long
+// run of provider calls.
+const reconcileBatch = 50
+
+// PendingForReconcile returns the pending orders that have reached their expiry age while carrying a
+// provider payment id — the ones where the money may well have moved but no callback ever told us.
+// The caller asks the provider for each one's real outcome before ExpireOrders writes them off.
+// Orders that never reached a payment are not returned: there is nothing to ask about.
+func (s *Service) PendingForReconcile(ctx context.Context) ([]OrderRef, error) {
+	ttl, err := s.store.orderTTL(ctx)
+	if err != nil {
+		return nil, err
+	}
+	rows, err := s.store.pendingForReconcile(ctx, ttl, s.clock(), reconcileBatch)
+	if err != nil {
+		return nil, err
+	}
+	out := make([]OrderRef, 0, len(rows))
+	for _, r := range rows {
+		ref, err := orderRef(r)
+		if err != nil {
+			return nil, err
+		}
+		out = append(out, ref)
+	}
+	return out, nil
+}
+
 // OrderItem returns a pending order's human title and the amount it charges, in the order's own
 // currency — the details a provider's item-lookup phase needs (VK's get_item). It reads the order
 // and the pack title, honouring the pack even if it was later deactivated (mirrors Fund).