Net the trip debt to one figure, and show payer, category and search on Shared

Shared view: the query already returned owner_name and effective_category, the
table just never rendered them. Paid by sits next to Splits because together
they are whose money went out and whose share it was. Search is client-side —
this endpoint returns all 1,267 split rows in one request with no pagination, so
there is nothing for a round-trip to narrow, and the sort was already
client-side. It matches description, merchant, notes, category and payer, but not
participant names: the dropdown does that, and "sonu" matching every row she is
split on would read as broken.

Trip owed collapses to one settle-up figure per person, with the breakdown
beside it so the net is auditable rather than asserted.

I argued against netting a few hours ago and was wrong. The claim was that the
grouped-payment allocation cleared each trip against the one-directional gross,
so netting would redefine that debt after the fact. The rows say otherwise:
Europe's $802.75 is 56 transactions Sonu actually paid across Rome, Venice, the
Dolomites, Bellagio, Lucerne and Paris on which I hold 25%, and paid_by_me is
$0.00 on every row of every trip because nothing has ever been recorded going
from me to her. Her side looked settled only because the allocation derived her
payment split from her gross, so it lands on zero by construction. The
one-directional view was hiding a live obligation, not protecting an allocation.

Nets now: Auckland Sonu +$1,077.25, Europe Sonu -$802.75, Sonu + Sunny -$936.34,
Europe Molina -$816.16.

Also correcting an error in my own reporting: I said Auckland's mirror was
$0.00. It is $428.39 — 17 Auckland rows Sonu paid that I hold a split on. Two
ad-hoc verification queries mis-joined on a nullable scope column and
under-reported the mirror side. The app code was never affected and the owed
column is still byte-identical.

The footnote now states the trap the netting exposes: a debt settled by a payment
left on the household tab still reads as outstanding on the trip. Payment 5
(Molina to Sonu, $1,605.49) is exactly that case and is left alone as a data
decision.

277 passing, build clean.

CLAUDE.md

@@ -291,19 +291,53 @@ viewer's side is the whole fix; an obligation lives on a row someone else paid
 for, so a viewer-as-payer figure can never contain it, and Sonu's Europe 2026
 read "you are owed $2,408.24" while omitting the $8,004.04 she owed.
 
-**Do not collapse the two into one signed net.** It looks like the obvious next
-step and it silently corrupts the scope allocation. The grouped-payment
-allocation (memory case `allocate_grouped_payments`) cleared Sonu's transfers
-against the trip debts chronologically, Europe first with the remainder to
-household — and the debt it cleared was the one-directional gross. Netting
-redefines Europe's debt as $7,201.30 after the fact, turning the $8,004.04
-already allocated into an $802.75 over-allocation with household understated by
-the same amount. The total stays right; the split between scopes stops being.
-Both halves therefore carry their gross and payments too (`owed_gross`,
-`paid_to_me`, `i_owe_gross`, `paid_by_me`) so a paid-up trip reads "settled"
-rather than a bare `0.00`. Verified byte-identical across the change: Auckland
-Sonu $1,505.64, Europe Molina −$816.16, Europe Sonu $0.00, Sonu + Sunny Sonu
-$0.00.
+**The API returns both halves whole; the trip page nets them for display.** One
+figure per person answers the only question the column exists for — what do we
+transfer to close this trip. The breakdown renders beside it, because a net
+nobody can decompose is how a wrong figure survives.
+
+**On whether to net — the reasoning reversed once, and the second answer is the
+right one.** The first objection was that the grouped-payment allocation (memory
+case `allocate_grouped_payments`) cleared each trip against the *one-directional*
+gross, Europe first with the remainder to household, so netting would redefine
+that debt after the fact. Checking the underlying rows overturned it: Europe's
+$802.75 is **56 real transactions Sonu paid** across Rome, Venice, the Dolomites,
+Bellagio, Lucerne and Paris on which Siddharth holds 25% — and `paid_by_me` is
+**$0.00 on every row of every trip**, because nothing has ever been recorded
+going from him to her. The one-directional view was concealing a live obligation,
+not protecting an allocation. Her side was paid in full and looked settled only
+because the allocation derived her payment split *from* her gross, so it lands on
+zero by construction.
+
+Current nets: Auckland Sonu **+$1,077.25** (1,505.64 − 428.39), Europe Sonu
+**−$802.75**, Sonu + Sunny **−$936.34**, Europe Molina **−$816.16**. The `owed`
+column itself was verified byte-identical when the mirror was added — $1,505.64,
+−$816.16, $0.00, $0.00.
+
+**A payment left on the household tab makes a settled trip debt read as
+outstanding.** Payment 5 (Molina → Sonu, $1,605.49) discharged the Europe debt
+between those two but carries `trip_id IS NULL`, so a trip-scoped net cannot see
+it and Europe still shows it owing. That is the cost of scope being optional, and
+the reason the Record Payment modal now asks. Fixable per row with
+`UPDATE split_payments SET trip_id = 1 WHERE id = 5` — not done, it is a data
+decision.
+
+### The Shared view shows payer and category, and is searchable (2026-08-02)
+
+`getSharedTransactions` already returned `owner_name` and `effective_category`;
+the table simply never rendered them. **Paid by** sits next to **Splits**
+deliberately — together they are the two halves of the question the page exists
+to answer, whose money went out and whose share it was. It shows the *effective*
+owner (`COALESCE(t.owner_id, s.owner_id)`), which is the account the spend left,
+and the same figure every balance on the page is computed from. Category uses the
+override-first COALESCE, so a correction made anywhere shows here.
+
+Search is **client-side**, unlike the transactions page. This endpoint returns
+every split row in one request (1,267 today) with no pagination, so there is
+nothing for a server round-trip to narrow, and the sort was already client-side.
+It matches description, merchant, notes, category and payer — deliberately **not**
+participant names, because the participant dropdown already does that and typing
+"sonu" matching every row she is split on would read as broken.
 
 ### Payment scope reaches the API (2026-08-02)