Populate payment method filter from real data instead of a guessed list

The previous fix hardcoded apple_pay/google_pay as extra filter options,
but Payment.method is free-text set by whatever the gateway reports, so
guessing at literal values was fragile and still didn't surface them for
this user. Add GET /api/payments/mypayments/methods returning the
distinct method values actually present in the user's payments, and have
the dashboard filter build its options from that instead. Also switch
the method filter from a startsWith match to an exact match, since the
values now come straight from the same column being filtered.

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 and display now recognize Apple Pay / Google Pay instead of only cash/card/EFT/voucher, and unrecognized method values are shown with a readable label instead of a raw snake_case/camelCase string.
+- 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.
 
 ## [1.0.1] - 2026-07-23