feat(payment): admin-editable ZarinPal settings + in-panel test payment

Lets the broker's ZarinPal merchant / sandbox / amount-unit be set from
Admin → درگاه پرداخت (persisted in payment.settings) instead of env +
redeploy, and adds a per-app "test payment" button that mints a real
ZarinPal StartPay link straight from the panel — no site wiring needed.

- migration 33_payment_settings.sql: singleton payment.settings + a
  transactions.is_test column. (33, not 32 — 32 is content_render_engine.)
- broker read-path precedence: per-client override > DB settings > env.
- POST /v1/admin/clients/:id/test-payment + GET/PUT /v1/admin/settings.
- admin UI: «تنظیمات زرین‌پال» tab + «پرداخت آزمایشی» button.

Adversarial-review fixes (2 confirmed HIGH):
- do NOT pre-seed the settings row — a seeded sandbox=TRUE default would
  override a production ZARINPAL_SANDBOX=false env and silently route real
  payments to sandbox.zarinpal.com until an admin untouched the toggle.
  No row → env governs until an admin saves.
- test transactions are tagged is_test and the webhook dispatcher skips
  them, so an admin smoke-test can never notify (or credit) a real client,
  regardless of metadata. Broker-authoritative, not consumer-dependent.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

deploy/README.md

@@ -23,9 +23,14 @@ ZarinPal gateway shared by FlatRender + meezi.ir + bargevasat.ir — ZarinPal on
 accepts callbacks on that one verified domain. It does NOT sit behind the API
 gateway (clients authenticate with an API key + HMAC). See
 [`PAYMENTS.md`](./PAYMENTS.md) for the integration contract. The `payment` schema
-is migration `31_payment_broker.sql` — on an existing DB volume it must be applied
-manually (migrations only auto-run on first volume creation):
-`docker exec -i fr2-postgres psql -U postgres -d flatrender < backend/db/migrations/31_payment_broker.sql`.
+is migrations `31_payment_broker.sql` (tables) + `33_payment_settings.sql`
+(admin-editable ZarinPal config + `transactions.is_test`) — apply BOTH, in order,
+on an existing DB volume (migrations only auto-run on first volume creation):
+```
+docker exec -i fr2-postgres psql -U flatrender -d flatrender < backend/db/migrations/31_payment_broker.sql
+docker exec -i fr2-postgres psql -U flatrender -d flatrender < backend/db/migrations/33_payment_settings.sql
+```
+The broker image expects `is_test` (migration 33) — deploy it together with both migrations.
 
 ## One-time setup (do these BEFORE the first `git push gitea master`)