feat(statements+analytics): normalise statement_type; fix analytics scoping

Groundwork for importing bank and loan statements alongside credit cards.

statement_type was whatever free text Gemini put in account_type ('Credit Card',
'credit card', 'credit_card', 'Business Card', 'ACCESS ADVANTAGE',
'multi-currency account'). The UI coped only by doing .includes("card"), which
breaks as soon as bank and loan statements arrive.

- Migration 0013 adds normalize_statement_type() + a BEFORE INSERT/UPDATE
  trigger and a CHECK constraint over credit_card|transaction|savings|loan|
  offset|investment|other. The trigger means the N8N workflow keeps working
  unchanged while it still sends free text. Raw value stays in account_type.
  Backfilled 99 existing rows.
- src/lib/statement-types.ts mirrors the vocabulary for the UI; statements page
  now filters by the real types and headlines balance vs amount due per type.

Analytics were scoped with INNER JOIN statements + s.owner_id, which silently
dropped all 180 manual/CSV transactions (statement_id IS NULL) from every
report. Switched all six routes to LEFT JOIN + COALESCE(t.owner_id, s.owner_id)
via shared fragments in src/lib/analytics-sql.ts, so the transfers/investment
exclusion that stops card-payment double counting stays consistent. Also
extended that exclusion to trip analytics, which had none.

Drive-by: /api/analytics/subscriptions was returning 500 on an unserialisable
BigInt from COUNT(*) + 1.

Verified against the live DB: monthly spend picks up the previously invisible
manual transactions (Apr 9,849.91 -> 14,286.70) and all four analytics
endpoints return 200.

src/lib/analytics-sql.ts

@@ -0,0 +1,32 @@
+// Shared SQL fragments for analytics queries, so spend/income semantics stay
+// identical across routes.
+//
+// Two rules every analytics query must follow:
+//
+// 1. Join `statements` with LEFT JOIN and scope on COALESCE(t.owner_id, s.owner_id).
+//    An INNER JOIN silently drops every manual/CSV transaction (statement_id IS
+//    NULL) — which is most of the reconciliation and cash-spend data.
+// 2. Exclude `transfers` and `investment` from spend. Once bank statements are
+//    imported, a credit-card payment appears twice: once as a debit leaving the
+//    bank account and again as the underlying purchases on the card statement.
+//    Categorising the money movement as `transfers` and excluding it here is what
+//    stops the double count. Investments are a balance-sheet move, not spend.
+
+/** Owner scoping that works for both statement-linked and manual transactions. */
+export const OWNER_SCOPE = `COALESCE(t.owner_id, s.owner_id)`;
+
+/** Join clause to pair with OWNER_SCOPE. */
+export const STATEMENTS_JOIN = `LEFT JOIN statements s ON s.id = t.statement_id`;
+
+/** Transaction types that represent money going out. */
+export const SPEND_TYPES = `('debit', 'fee', 'interest')`;
+
+/** Effective category, honouring overrides. Never NULL. */
+export const EFFECTIVE_CATEGORY = `COALESCE(o.category_override, t.category, 'other')`;
+
+/**
+ * Predicate excluding money-movement categories.
+ * The COALESCE matters: a bare `category NOT IN (...)` evaluates to NULL for
+ * uncategorised rows, which silently drops them from spend totals.
+ */
+export const EXCLUDE_NON_SPEND = `${EFFECTIVE_CATEGORY} NOT IN ('transfers', 'investment')`;