feat(payments): send no fiscal receipt; keep the code switchable

The merchant accepts payments as a sole proprietor on НПД, which is outside
54-ФЗ: there is no online cash register, YooKassa does not serve receipts for
that regime at all (checked with their support), and each operation is reported
by the merchant to «Мой налог», which issues the чек. So no `receipt` is sent
with a payment or a refund.

This also removes a failure class rather than just code: a malformed receipt
was an API error at payment creation, which broke the purchase outright.

The fiscal code is kept dormant rather than deleted. All of it now sits behind
one switch, `BACKEND_YOOKASSA_VAT_CODE`: unset — the default — builds and sends
nothing; a 54-ФЗ rate code turns «Чеки от ЮKassa» back on unchanged. The return
is foreseeable, which is why the switch exists: НПД carries an annual income
ceiling, and losing the regime puts 54-ФЗ back in force, at which point this is
a deploy-variable edit instead of writing the integration again.

The D36 email anchor still gates a direct purchase. It had two justifications —
a recovery anchor and the receipt address — and only the second is gone; without
an email a paying customer who loses the account loses the chips with it. What
was missing is that the rule was enforced but never communicated: the wallet
showed the packs to a player signed in through VK or Telegram in a browser, and
tapping Buy produced a bare "something went wrong". It now says "add an email in
your profile" in the buy tab instead, linking to the profile; spending
already-earned chips is untouched. The predicate is a pure function so it is
covered by the node-env unit tests rather than needing a browser.

Tests: the receipt-off default is pinned by an integration test asserting a
purchase carries no receipt, and the dormant path by one that switches a VAT
code on and checks the receipt reappears with the right fiscal attributes;
plus unit coverage for the enable predicate and the wallet's email rule.

A note for whoever runs the numbers next: the shared (svelte + i18n) chunk is
now 40 bytes under its 31 KB gzip budget.

Decision D51 revised.

.claude/CLAUDE.md

@@ -256,12 +256,14 @@ The native Android app is a Capacitor 8 wrapper of the `ui` SPA, scaffolded unde
   - **YooKassa DOES have a test mode** — a separate *test shop* (own shopId/secret, test cards, up to
     20 of them), and webhooks/receipts/refunds all work there. The whole rail is verifiable on the
     contour without real money; don't plan around "no test payments".
-  - **YooKassa has no cabinet-side generic чек.** Unlike Robokassa's cloud kassa, «Чеки от ЮKassa»
-    registers a receipt **only if the request carries `receipt`** — so the itemized receipt is
-    mandatory code on both payment and refund. `payment_subject`/`payment_mode`/`vat_code` are fields
-    *inside* `receipt.items[]` (54-ФЗ tags 1212/1214/1199), documented under the receipts section, not
-    the payment API — easy to miss. A malformed receipt is an API error at payment creation, so it
-    breaks purchases loudly rather than silently skipping the fiscal document.
+  - **We send NO receipt: the merchant is on НПД, which is outside 54-ФЗ**, and YooKassa does not
+    serve receipts for that regime (checked with their support). Reporting goes to «Мой налог».
+    The fiscal code is kept dormant behind `BACKEND_YOOKASSA_VAT_CODE` — unset = send nothing, a
+    54-ФЗ rate code turns «Чеки от ЮKassa» back on (the НПД income ceiling makes that foreseeable).
+    Gotcha if you ever switch it on: `payment_subject`/`payment_mode`/`vat_code` are fields *inside*
+    `receipt.items[]` (54-ФЗ tags 1212/1214/1199), documented under the receipts section, not the
+    payment API — easy to miss; and a malformed receipt is an API error at payment creation, so it
+    breaks purchases rather than silently skipping the fiscal document.
   - **The gateway cannot import `backend/internal/*`** (separate module + Go's internal rule), so a
     security list shared by both hops either lives in `pkg/` or is enforced backend-side. The YooKassa
     sender allowlist is enforced in the backend, with the gateway forwarding the real peer IP as