feat(admin): transaction management

Sprint 24.

New features/admin/transactions/ module. AdminTransactionsLocalGateway
derives one synthetic transaction per Sprint 23's seeded mock order rather
than a separate dataset, keeping order numbers/totals consistent across
the two mock feature areas.

- list: search, status filter, type filter (payment/refund/qr_payment),
  pagination, CSV export
- retry failed transactions (appends an audit entry)
- fraud flag toggle
- per-transaction audit log (creation/retry/fraud-flag-change), viewed via
  dialog - intentionally separate from the system-wide audit/security log
  planned for Sprint 26 (Monitoring)
- wired into /:lang/backoffice/transactions, replacing the coming-soon
  placeholder

docs/ADMIN.md + docs/BACKEND.md (new item 13) updated.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/BACKEND.md

@@ -144,6 +144,14 @@ Plus, if authenticated history/wishlist/compare/saved-searches sync is wanted: `
 
 ---
 
+## 13. Transactions (Sprint 24, mock/local)
+
+**Current behavior:** `features/admin/transactions/` exists (list, retry-failed, fraud flag, per-transaction audit log, CSV export) against `AdminTransactionsLocalGateway`, which derives one synthetic transaction per seeded mock order from item 7's `AdminOrdersLocalGateway` — no real payment/transaction data exists.
+
+**Needed:** a real payments/transactions domain (card, QR, cash-on-delivery), linked to orders, with retry semantics matching whatever the actual payment provider supports, and fraud-flag persistence.
+
+**Frontend files:** implement `AdminTransactionsApiGateway` against `AdminTransactionsGateway` (`services/admin-transactions-gateway.interface.ts`) and rebind via an injection token.
+
 ## Known reliability issues
 
 ### Production 502/504 Bad Gateway on refresh / back-navigation