orders phase 2: order_transaction_links, and move every reader to it (board 205)

Phase 1 read linkage out of expense_metadata, which is shaped as ONE ROW PER
TRANSACTION — transaction_id UNIQUE, matched_transaction_id partial-unique — so
every multiplicity it expresses is smuggled through a string key (0029 keys
split shipments <entity_key>#f<fact_id>). A BNPL plan needs four rows against
one order and has no such trick available.

Migration 0030 adds order_transaction_links (many-to-many, keyed on entity_key
rather than entities.id: finance-app does not model the spine and must not hold
an FK across a boundary a re-extraction can decompile) and backfills all 63
existing bridge rows.

THE UNIQUENESS RULE WAS WRONG FIRST TIME, in the most on-brand way available.
It read (entity_key, leg_kind, COALESCE(leg_index, 0)), so two shipment legs of
the same order — both leg_index NULL — collapsed to one key and ON CONFLICT DO
NOTHING dropped one SILENTLY. Caught only because the backfill reported 62
against 63 candidates. The row it ate was order_amazon_249-4859367-0690246's
$130.00 second shipment, the same order named in migration 0029's comment as
the reason split shipments need distinct keys at all. What identifies a leg
depends on its kind: an instalment by its INDEX, a shipment by its FACT, a
whole-order charge by neither.

ALL FOUR READERS MOVE TOGETHER, links first with expense_metadata as fallback:

  - LINK_LATERAL (list txn_count/first_txn_id, and the has_transaction facets
    that read it)
  - the detail page's transactions query
  - /api/transactions/[id]/order
  - the order_ctx lateral in queries.ts

Moving fewer is not a smaller change, it is an inconsistent one: the matcher's
four links for order_ebay_14-11714-95953 come with no expense_metadata row, so
a half-move would show four instalments on the detail page while the list said
txn_count = 0 and put the order on the wrong side of BOTH has_transaction
filters. Verified after: detail 4 legs, list txn_count 4, has_transaction=yes
includes it, =no excludes it.

UNION not UNION ALL on transaction_id — after the backfill the same charge is
legitimately in both stores and counting it twice would show "2 charges" on a
single-payment order.

order_platform is deliberately NOT coalesced with the link's platform. It gates
the receipt disclosure arrow on /transactions, and a BNPL leg has no receipt
behind it — filling it in put an arrow on four Afterpay rows that expand to
nothing, which is the exact promise the arrow exists to avoid making. Separate
leg fields carry the sub-line instead ("1 of 4 - DJI Air 3 Fly More Combo").
order-details.tsx now also requires a real receipt (platform present) before
rendering, because the endpoint can answer with a link alone.

Two invariant views, both empty and expected to stay so: order_link_orphans
(spine re-keying silently orphans a TEXT key — bridge links are rebuildable,
`manual` ones are lost curation) and order_link_drift (the two stores
disagreeing). The plan's suggested fix for drift — widening the bridge's NOT
EXISTS guard to "neither store has it" — was NOT taken: the expense_metadata
INSERT has no ON CONFLICT, so re-attempting an order that already has a receipt
row would duplicate it. Detecting is cheap; a non-idempotent re-write is not.

Unchanged: order_feed 6,265, order_spend AUD 4,895 / $442,651.80. Links 75.

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

@@ -38,7 +38,30 @@ export async function GET(
     [Number(id)]
   );
 
+  // Phase 2 (board 205). A BNPL leg has NO expense_metadata row of its own —
+  // the plan is four transactions against one order — so without this the four
+  // Afterpay debits behind the A$1,599 DJI drone stay four bare "Afterpay
+  // $399.75" rows naming nothing. That is the surface where this was noticed.
+  const link = await queryRow<{
+    entity_key: string; leg_kind: string; leg_index: number | null;
+    leg_count: number | null; canonical_name: string | null;
+    platform: string | null; order_total: string | null; currency: string | null;
+  }>(
+    `SELECT l.entity_key, l.leg_kind, l.leg_index::int, l.leg_count::int,
+            e.canonical_name, o.platform, o.order_total, o.currency
+       FROM order_transaction_links l
+       LEFT JOIN entities e      ON e.entity_key = l.entity_key
+       LEFT JOIN entity_orders o ON o.entity_id = e.id
+      WHERE l.transaction_id = $1
+      LIMIT 1`,
+    [Number(id)]
+  );
+
   // Not an order — most transactions aren't. Null, not 404: the caller is
   // asking "is there a receipt behind this?", and "no" is a normal answer.
-  return NextResponse.json(row ?? null);
+  if (!row && !link) return NextResponse.json(null);
+
+  // expense_metadata carries the itemised receipt and stays primary; the link
+  // adds what it cannot express — which order this is a leg OF, and which leg.
+  return NextResponse.json({ ...(row ?? {}), order_link: link ?? null });
 }