transactions: let a gift card be a payment method you can pick

`credits` has been a valid payment_method since migration 0018, which added it
so the order pipeline could file gift-card-funded orders. It reached the
database, `needsCardMatch()` (which holds those rows out of reconciliation) and
`bankLabel()` (which renders them "Gift Card"). It never reached the two places
a human touches it.

So entering a gift-card purchase by hand was impossible: the dropdown stopped at
"Other", the row took the NULL default, and NULL is *reconcilable* — it joined
the pending queue to be offered card matches within 3 days and 1% that cannot
exist, because the balance already paid the bill. Accepting one is the
destructive case the cash exclusion documents: reconciled manual rows are
filtered out of every query, so the spend vanishes while an unrelated card row
claims to be it.

- `src/lib/payment-methods.ts` — one canonical list, mirroring the
  `statement-types.ts` pattern, plus the TS mirror of `needsCardMatch()`.
- `PATCH /api/transactions/[id]` — the `VALID_METHODS` literal omitted
  `credits`, so the API answered 400 for a value the CHECK constraint admits
  and 372 live rows already carry. It validates against the list now.
- `POST /api/transactions` — validated at all, so a bad value is a 400 naming
  the field rather than a 500 carrying a Postgres error.
- Add modal — offers every method, and explains the consequence when you pick
  one that suppresses reconciliation. Relabelled "Paid by" → "Payment method",
  which the edit modal uses for the *owner*; they are different questions.
- Edit modal — had no payment-method field at all, so an existing row wrongly
  in the queue could not be corrected. Manual rows only: the queue is
  `statement_id IS NULL`, so it decides nothing on a statement row.

The test asserts the list against `pg_get_constraintdef` and evaluates
`needsCardMatch()` as real SQL rather than re-implementing it, so the next
migration that widens the constraint fails the suite instead of drifting for
two months. Mutation-tested by dropping `credits`.

Unit 130 pass, integration 206 pass (the integration DB needed `npm run
test:setup` first — `.env.test` still named a stale container IP).

src/app/api/transactions/[id]/route.ts

@@ -3,6 +3,7 @@ import { getTransactionById, canAccessTransactions } from "@/lib/queries";
 import { getCurrentUser } from "@/lib/auth";
 import { prisma } from "@/lib/db";
 import { queryRaw } from "@/lib/db";
+import { isPaymentMethod } from "@/lib/payment-methods";
 
 const VALID_TYPES = ["debit", "credit", "payment", "refund", "fee", "interest", "transfer"];
 
@@ -90,9 +91,12 @@ export async function PATCH(
 
   // payment_method is a property of the transaction itself, not a user override
   // of extracted data, so it lives on the transactions table.
+  //
+  // The allowlist is PAYMENT_METHODS, not a local literal: this one omitted
+  // 'credits' from migration 0018 until 2026-08-17, so the DB admitted a
+  // gift-card row that this route then refused to set or correct.
   if (payment_method !== undefined) {
-    const VALID_METHODS = ["card", "cash", "bank_transfer", "other"];
-    if (payment_method !== null && !VALID_METHODS.includes(payment_method)) {
+    if (payment_method !== null && !isPaymentMethod(payment_method)) {
       return NextResponse.json({ error: "Invalid payment_method" }, { status: 400 });
     }
     await queryRaw(