fix(orders): the restaurant is the merchant, not the courier

Reverses a change made on request. The platform in the headline
fragmented the merchant: the same restaurant read as two, depending on
who carried the bag, and that is not a distinction anyone rating the food
cares about. It also already has a home — the expandable Order details
panel renders expense_metadata.platform next to its heading, which is
where the user asked for it.

The fragmentation was worse than cosmetic. merchantVerdict joined on an
exact merchant_normalized, and the platforms capitalise differently
("TEG Kebabs & Biryani" on Uber Eats, "TEG KEBABS & BIRYANI" on
DoorDash), so one restaurant kept two separate histories and a "never
again" recorded through one app never warned in the other — silently
defeating the point of the memory. Now case-folded; verified on real
data, where the DoorDash order sees 1 prior verdict against 0 before.

81 existing descriptions backfilled in one transaction, dry-run first and
dumped beforehand. The regex is anchored to the end so suburb parens
survive: "Order - Coles (Wyndham Vale) (Uber Eats)" becomes
"Order - Coles (Wyndham Vale)", not "Order - Coles".

src/lib/order-reviews.ts

@@ -151,7 +151,12 @@ export async function merchantVerdict(
        JOIN expense_metadata em
          ON em.transaction_id = r.transaction_id
          OR em.matched_transaction_id = r.transaction_id
-      WHERE em.merchant_normalized = $1
+      -- Case-folded: the platforms capitalise the same restaurant differently
+      -- ("TEG Kebabs & Biryani" on Uber Eats, "TEG KEBABS & BIRYANI" on
+      -- DoorDash). An exact match split one restaurant's history in two, so a
+      -- "never again" recorded through one app never warned you in the other —
+      -- silently defeating the whole point of the memory.
+      WHERE lower(em.merchant_normalized) = lower($1)
         AND ($2::int IS NULL OR r.transaction_id <> $2)
       ORDER BY t.transaction_date DESC, r.participant_id
       LIMIT 50`,