Three defects on one surface, all invisible while a transaction has exactly
one expense_metadata row — which is almost always.
1. ORDER BY (transaction_id = $1) DESC did the opposite of its comment.
Postgres orders DESC as NULLS FIRST, and the row that merely POINTS at the
transaction has a NULL transaction_id, so the clause written to prefer the
owned row preferred the other one — in exactly the case it exists for.
matchTransaction already spelled out NULLS LAST; now so do this and
GET /api/transactions/[id]/order, which had no ORDER BY at all and could
read a different row from the one an enrichment had just written.
2. replaceLineItems takes an optional metadataId. The match resolves a row
through a platform-filtered join; re-picking independently here can land
the write on a row the match ruled out.
3. previous_line_items on intake_batches is the undo baseline, recorded once
per batch under COALESCE and read back. Returning whatever was just read
hands a pantry retry its own write as the "previous" state, so undo
restores the thing it undid. Migration 0034 is unapplied anywhere, so the
column is added there rather than in a 0035.
siddharthd
f9638cc5e5