feat(payments): add the payments schema, currency domain and money type

Stand up the payments data foundation: a self-contained `payments` Postgres
schema for the in-game currency, wallets, benefits, catalog, orders and the
append-only operations ledger, behind a domain package — nothing wired to real
money yet.

- Migration 00010: the `payments` schema and a NOLOGIN confinement role (ALL on
  payments.*, nothing on backend); the ledger with a BEFORE UPDATE/DELETE
  append-only trigger and a partial idempotency index; the materialised
  balances/benefits; the catalog (atoms seeded) + products + per-method prices;
  the typed single-row config; orders and payment_events. There is no
  cross-schema foreign key — account_id is a plain uuid kept consistent in code,
  which keeps the domain extractable. Expand-contract and reversible.
- Money is a bigint in the currency's minor units carried by a `Money` value
  type (exact, math/big): no float ever touches an amount, and a whole-unit
  currency cannot hold a fraction.
- Extend jetgen to generate the payments schema; construct the service in the
  composition root behind a narrow interface with a boot reachability check.
- Tests: integration (role confinement via SET ROLE, the append-only trigger,
  CHECK constraints, the idempotency index, and a forward+backward migration),
  Money unit tests, and an import-boundary test keeping the payments jet code
  private to the domain.
- Docs: PLAN.md, docs/PAYMENTS.md (+ _ru mirror) updated to the built model.

docs/PAYMENTS.md

@@ -49,7 +49,8 @@ The chip balance is **segmented by `source`** — the platform where the chips w
 | `direct`   | Robokassa purchase (web / native)|
 
 A single account holds all three segments simultaneously: `balance = (account_id, source)`,
-exactly three rows. Segmentation is **not** per-identity — see §6.
+up to three rows — a row is materialised lazily on the segment's first funding, and an absent
+segment reads as zero. Segmentation is **not** per-identity — see §6.
 
 Why segmented, not one pooled balance: store rules forbid activating value that was paid
 for outside the store's own cash desk. Chips funded inside VK (Votes) may only be spent in
@@ -302,8 +303,11 @@ confirms the exact НПД scheme with a tax advisor.)
 
 The payments domain lives in its **own schema `payments`** in the shared Postgres instance,
 with its own DB role (rights limited to `payments`) and a domain package behind a hard
-interface. Cross-schema FKs to `backend.accounts` keep the chip↔benefit spend atomic in one
-transaction. Durability is **PITR** (continuous WAL archive), independent of DB topology.
+interface. There is **no cross-schema foreign key** to `backend.accounts` — an account id is a
+plain value here, kept consistent in code and joined to the tombstoned account /
+retained-identities dossier by the stable id. That keeps the chip↔benefit spend atomic
+**within `payments`** and the domain extractable into its own database. Durability is **PITR**
+(continuous WAL archive), independent of DB topology.
 
 Core tables (final names/columns fixed in `PLAN.md`):
 
@@ -318,9 +322,10 @@ Core tables (final names/columns fixed in `PLAN.md`):
   (pending/paid/expired).
 - **payment_events** — succeeded/failed/refunded for the dispatcher.
 
-Legacy `accounts.hint_balance` and `accounts.paid_account` are **deprecated** and dropped
-(expand-contract) in favour of the segmented model; neither was ever set in prod (no purchase
-flow existed), so legacy values are zeroed.
+Legacy `accounts.hint_balance` and `accounts.paid_account` are **deprecated** in favour of the
+segmented model and dropped in a later **contract-phase** migration (expand-contract, after the
+currency core flips reads and Release 2 — image rollback stays DB-safe); neither was ever set in
+prod (no purchase flow existed), so legacy values are zeroed.
 
 ## 15. Glossary
 

docs/PAYMENTS_ru.md

@@ -48,8 +48,9 @@
 | `telegram` | Покупка за Stars TG                |
 | `direct`   | Покупка через Robokassa (web / native) |
 
-Один аккаунт держит все три сегмента одновременно: `баланс = (account_id, source)`, ровно
-три записи. Сегментация **не** по привязке (identity) — см. §6.
+Один аккаунт держит все три сегмента одновременно: `баланс = (account_id, source)`, до трёх
+записей — запись материализуется лениво при первом пополнении сегмента, отсутствующий сегмент
+читается как ноль. Сегментация **не** по привязке (identity) — см. §6.
 
 Почему сегментировано, а не один общий баланс: правила сторов запрещают активировать
 ценность, оплаченную мимо их кассы. Фишки, пополненные внутри VK (Голоса), тратятся только
@@ -304,9 +305,11 @@ INSERT** (никогда UPDATE/DELETE — полный аудит). Балан
 
 Платёжный домен живёт в **своей схеме `payments`** в общем инстансе Postgres, со своим
 DB-ролём (права только на `payments`) и доменным пакетом за жёстким интерфейсом.
-Cross-schema внешние ключи к `backend.accounts` держат трату «Фишки↔бенефит» атомарной в
-одной транзакции. Сохранность — **PITR** (непрерывный WAL-архив), независимо от топологии
-базы.
+**Cross-schema внешнего ключа** к `backend.accounts` **нет** — идентификатор аккаунта здесь
+обычное значение, согласуемое в коде и связываемое с tombstone-аккаунтом / досье
+retained-identities по стабильному id. Это держит трату «Фишки↔бенефит» атомарной **внутри
+`payments`** и делает домен извлекаемым в свою базу. Сохранность — **PITR** (непрерывный
+WAL-архив), независимо от топологии базы.
 
 Основные таблицы (финальные имена/колонки — в `PLAN.md`):
 
@@ -322,9 +325,11 @@ Cross-schema внешние ключи к `backend.accounts` держат тра
   (pending/paid/expired).
 - **payment_events** — succeeded/failed/refunded для диспетчера.
 
-Legacy `accounts.hint_balance` и `accounts.paid_account` **устаревают** и удаляются
-(expand-contract) в пользу сегментированной модели; ни то, ни другое в проде никогда не
-выставлялось (потока покупки не было), поэтому legacy-значения обнуляются.
+Legacy `accounts.hint_balance` и `accounts.paid_account` **устаревают** в пользу
+сегментированной модели и удаляются в отдельной **contract-миграции** (expand-contract, после
+того как валютное ядро переключит чтения, и после Release 2 — откат образа остаётся безопасным
+для БД); ни то, ни другое в проде никогда не выставлялось (потока покупки не было), поэтому
+legacy-значения обнуляются.
 
 ## 15. Словарь