Accept grocery receipts scanned in pantry as candidate spend

Adds /api/receipts/ingest as a sibling to the order lane, sharing its shape but
making one decision differently: nothing is parked. An order can wait for its
statement because it is already visible as an email; a gift-card grocery shop is
visible nowhere at all, so a scan that produces no transaction produces nothing
anyone can see. Every payment becomes a manual row immediately and the existing
pending-reconciliation queue resolves the ones with a card leg coming.

One transaction per tender leg. A $114.57 shop settled $40.75 gift card +
$73.82 Mastercard has a statement line for $73.82 only. A single row marked
credits is excluded from the queue while that line double-counts; marked card it
is searched for at 1% of $114.57 and never matches. Either way the shop books
$188.39. Per-leg rows make each amount the settled amount, so the matcher works
untouched.

Reconciliation now carries expense_metadata across. It already moved overrides,
tags and splits from the manual row to the statement row and left metadata
behind, which did not matter while metadata only came from an email that made
its own transaction. It matters now that it carries a shop's line items:
unmoved, the contents vanish at exactly the moment the statement line appears,
and COLES 0556 MANOR LAKES stays as unreadable as before anything was scanned.
transaction_id is UNIQUE, so a statement row that already has metadata keeps it
and the pantry row is flagged rather than raising a constraint violation.

Also regenerates the Prisma model. card_last4, currency, flags, reconciled_at,
matched_transaction_id, platform and route have been in the database since
migrations 0019/0020 and were absent from schema.prisma — regenerating the
client from it would have dropped columns the order lane writes on every ingest.

23 integration tests against the real schema, built from the three receipts that
drove the design. Existing suites unchanged: 104 unit, 144 integration.

prisma/migrations/0027_pantry_receipt_source/migration.sql

@@ -0,0 +1,37 @@
+-- Receipt scans as a second producer on the order lane.
+--
+-- A grocery shop paid with a supermarket gift card settles against no statement and
+-- arrives in no mail, so the pantry scan is the only touchpoint that ever sees it. Rather
+-- than a second ingestion mechanism, a scan lands as a manual transaction
+-- (statement_id IS NULL) and the existing pending-reconciliation queue resolves it —
+-- with needsCardMatch() already excluding cash/credits rows for which no card leg is
+-- ever coming.
+
+-- The receipt as text, kept as evidence rather than parsed into a decision. The token
+-- that distinguishes a gift card from a bank card was only findable by reading two
+-- payments side by side on one receipt; whether it holds across merchants is answerable
+-- from stored blocks and not at all from none.
+ALTER TABLE expense_metadata
+  ADD COLUMN IF NOT EXISTS tender_raw TEXT;
+
+-- The image the extraction came from. Not the idempotency key -- a photo and the store's
+-- e-receipt PDF of one purchase hash differently -- but exact where it applies, and the
+-- only thing a later cross-source dedupe against an emailed or Paperless copy could match
+-- on.
+ALTER TABLE expense_metadata
+  ADD COLUMN IF NOT EXISTS receipt_sha256 TEXT;
+
+CREATE INDEX IF NOT EXISTS idx_expense_receipt_sha256
+  ON expense_metadata (receipt_sha256)
+  WHERE receipt_sha256 IS NOT NULL;
+
+-- Legs of one split-tender shop, so a $40.75 gift-card row can be shown as part of a
+-- $114.57 purchase instead of an orphan. The shared receipt identity is carried in
+-- order_reference ('pantry:<merchant:store:register:number:date>#<leg>'); this column is
+-- what makes the group queryable without parsing that string.
+ALTER TABLE expense_metadata
+  ADD COLUMN IF NOT EXISTS receipt_group TEXT;
+
+CREATE INDEX IF NOT EXISTS idx_expense_receipt_group
+  ON expense_metadata (receipt_group)
+  WHERE receipt_group IS NOT NULL;