feat(payments): chip wallet, store-compliance gate and benefit application

Stand up the internal chip/benefit mechanic behind the narrow payments interface:
context-aware balances and benefits, an atomic chip spend, admin grants as
zero-price value sales, the one-directional store-compliance gate (VK/TG same-
origin only, web draws direct→vk→tg, VK-iOS frozen, untrusted fail-closed), and
per-origin hint and no-ads application with term stacking. Reads are served from
an in-process, account-keyed write-through cache (mirroring the suspension gate),
so hot paths issue no query to the payments schema.

Flip the online-game hint wallet and the ad-banner suppression from the deprecated
accounts.hint_balance / paid_account columns to the payments benefit (a hint
balance no longer suppresses the banner — only a no-ads benefit does), and fold
chip segments and benefits by origin on account merge, inside the merge tx. Add
the GET/POST /api/v1/user/wallet edge chain (REST → Connect → FlatBuffers) plus
its codec unit test; no wallet UI yet.

Bring the frozen owner decisions log into the repo at
docs/PAYMENTS_DECISIONS_ru.md (it was untracked under .vscode) and reference it
from PLAN.md; record the read-cache design and the present-sources interface in
PLAN.md and docs/PAYMENTS.md (+ RU mirror).

docs/PAYMENTS.md

@@ -273,6 +273,16 @@ the **origin benefit applicable in the current context** rather than one global
 `(account, origin)` are a fast **materialized** cache, updated **in the same transaction** as
 the ledger write, and recomputable from the ledger for reconciliation.
 
+**In-process read cache.** On top of the materialized tables, the payments package keeps an
+in-process, account-keyed, write-through cache of each account's segments and benefits, so the
+hot read paths — the ad-eligibility check, hint availability, the wallet view, the spend gate
+— issue **no** query to the `payments` schema on the steady-state path. It is invalidated on
+every payments mutation (spend / grant / fund / refund / merge) and re-read from the
+materialized tables on a miss (the same write-through pattern the account-suspension gate
+uses). Single-instance, matching the deployment; a multi-instance backend would need a shared
+cache. Identity-presence (which segments are awake, §6) is supplied by the caller, not cached
+here, so unlink/re-link takes effect immediately.
+
 **Admin rewards.** An admin grants **concrete values only** (no-ads / hints) — **never
 chips** (a gifted currency balance = a store cash-desk bypass). The admin **picks the
 origin** at grant time (compliance is on them: `origin=vk` point-wise/low-volume = low risk,