Normalize user-facing payment method to cash/card/eft/voucher

Per feedback, stop trying to surface every gateway-reported wallet
type (apple_pay, google_pay, yoco, ...) as its own filter/display
value on the user payment history page. Both /mypayments and
/mypayments/methods now fold anything outside the four manual-entry
methods into "card", both in the returned data and in the filter
query, so Apple Pay/Google Pay payments show up under Card.

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

CHANGELOG.md

@@ -14,7 +14,7 @@ and this project follows [Semantic Versioning](https://semver.org/).
 ### Fixed
 
 - Cashup/reports: payments tagged with a digital wallet method (e.g. `apple_pay`, `google_pay` from online checkouts) are now bucketed as "card" for reconciliation instead of silently falling into "other".
-- User dashboard payment history: the method filter no longer offers a hardcoded, guessed set of values (which silently excluded real gateway-reported methods and matched them inconsistently). It now queries the distinct methods actually present in the user's payments (new `GET /api/payments/mypayments/methods` endpoint) and filters on an exact match, so every real method — including wallet types like Apple Pay/Google Pay — is filterable and displayed with a readable label instead of a raw string.
+- User dashboard payment history: `GET /api/payments/mypayments` and its new `/methods` endpoint now normalize `method` to cash/card/eft/voucher — any other gateway-reported value (apple_pay, google_pay, yoco, etc.) is reported and filterable as "card" — instead of exposing raw, inconsistent gateway strings the filter dropdown didn't know about.
 
 ## [1.0.1] - 2026-07-23