feat(payments): refund engine (best-effort revoke, never negative)

The last money-intake slice: reverse a paid order best-effort, exactly once. All
refunds are admin-triggered (E7) — no rail pushes an unsolicited refund (Robokassa
via its refund API / cabinet, VK via support, Telegram via refundStarPayment), so
this ships the engine they all converge on, not a webhook.

The Refund method matches the paid order, appends a refund ledger row (idempotent on
(provider, provider_refund_id) — distinct from the fund's payment id, so both
coexist), and revokes the funded chips floored at 0 (never negative — D27,
balances_chips_chk). When the chips were already spent, the unrecoverable remainder
is recorded as a per-account loss + abuse flag in the new additive
payments.account_risk table (read by the E7 report). The refund ledger row's chip
delta is what was actually reclaimed (the ledger stays reconcilable); the full
reversal rides in the snapshot; the order stays paid.

Additive migration (a new table only) -> rollback-safe, no contour wipe. Robokassa
refund-status polling is deferred (a worker not worth it at low chargeback volume);
failed events are not wired (no rail signals a hard post-charge server decline).

Tests: integration (full revoke; revoke-after-spend = floor-0 + loss + abuse;
duplicate idempotent; unpaid-order guard). Docs: PAYMENTS(+ru) §9, PLAN (E5 -> DONE).

docs/PAYMENTS.md

@@ -241,14 +241,22 @@ existing `botlink` push / email relay. "Payment failed" (an **active** provider
 an abandoned pending) is surfaced to the user; "payment succeeded" is a hook (email / bot
 message).
 
-**Refunds.** ToS is **non-refundable** — we do not offer refunds to the user. An admin may
-issue a **manual** refund (edge case: a user demands one shortly after paying / closes their
-account — tie into `accountdelete`, which already preserves messages). **External** refunds
-(chargeback / store decision / TG / VK) are honoured: the system takes the `refunded` event,
-**best-effort** revokes the benefit (never going negative; if chips were already spent, it
-records the loss + an abuse flag), and writes to the ledger. The ledger is **export-ready**
-for future tax reporting and Robokassa reconciliation (reconciliation itself is not built
-yet; the schema stays compatible).
+**Refunds.** ToS is **non-refundable** — we do not offer refunds to the user. Refunds are
+**admin-triggered** (the E7 console), since no rail pushes an unsolicited refund: Robokassa
+refunds run through its refund API / merchant cabinet (auto-polling a rail's refund status is a
+deferred worker, not worth it at low chargeback volume), VK refunds are handled by support, and
+Telegram Stars refunds are issued with `refundStarPayment`. All of them converge on one engine —
+the `Refund` method (`internal/payments`): it matches the paid order, appends a **refund** ledger
+row (idempotent on `(provider, provider_refund_id)` — the refund id is distinct from the fund's
+payment id, so the two rows coexist under the same partial-unique index), and **best-effort revokes
+the funded chips floored at 0** (never negative — D27, `balances_chips_chk`). When the chips were
+already spent, the unrecoverable remainder is recorded as a per-account **loss + abuse flag**
+(`payments.account_risk`, read by the E7 report). The refund ledger row's chip delta is what was
+actually reclaimed, so the ledger stays reconcilable against the balance; the **full** reversal
+(money, original chips, loss) rides in the row's snapshot. The order stays `paid` — the refund lives
+in the ledger + a `refunded` payment event, not in the order status. A duplicate refund reverses
+nothing. The ledger is **export-ready** for future tax reporting and reconciliation (the reconciler
+itself is not built yet; the schema stays compatible).
 
 ## 10. Ads