feat(expenses+interests): trip/event grouping (lightweight)

Per the trips/events design discussion: instead of building a full
events domain (table + CRUD UI + calendar) for the 6–12 yacht shows
a year, ship the cheap version that covers the actual asks.

Expenses — `tripLabel` free-text:
- New `expenses.trip_label` text column (migration 0039) + index for
  filter / autocomplete lookup.
- Validator: createExpenseShape + listExpensesSchema +
  exportExpensePdfSchema.filter all accept tripLabel.
- Service: createExpense + updateExpense persist; listExpenses filters;
  new `listTripLabels(portId, search?)` returns distinct values
  ordered by most-recent expenseDate so the autocomplete surfaces
  recently-used labels first.
- New `GET /api/v1/expenses/trip-labels` endpoint (gated by
  expenses.view) backs the autocomplete.
- Form dialog: native `<datalist>` powered by the autocomplete query
  so reps don't end up with "Palm Beach 2026" / "palm-beach 2026"
  fragmented across two PDF sections.
- Expense list: new "Trip" column (badge) + free-text filter.
- Detail page: trip label rendered alongside Category / Payer.
- PDF export: GroupBy gains 'trip'; filter.tripLabel narrows the
  export. Untagged rows fall under "(no trip)".
- Trim/normalize on write so " Palm Beach 2026 " === "Palm Beach 2026".

Interests — event tagging via existing tag system:
- Reps can tag interests with an event tag (e.g. "Palm Beach 2026")
  via the existing InlineTagEditor on the detail page; tags are
  port-scoped and reusable.
- Interest list now has a TagPicker filter rendered next to the
  FilterBar so reps can sort prospects by event attended ("show me
  every lead from Palm Beach"). Hidden 'relation'-typed
  FilterDefinition for tagIds wires URL round-trip + saved-views
  capture without rendering inside the FilterBar.
- FilterBar deserializer now handles `relation` types as comma-joined
  arrays on URL load.

Why a free-text trip label and not a trips table:
- 6–12 events/year doesn't justify a domain. The CRUD UI cost would
  be most of the engineering, and reps already have the events on
  their personal calendars.
- If usage proves demand for per-event ROI dashboards or richer
  attribution, promote to a real `trips` table later. Migration
  path: trip_label → tripId is a backfill+swap.

Test status: 1168/1168 vitest. tsc clean. Migration 0039 applied
in dev (also caught + fixed an unrelated audit-v3 follow-up: 0037
had `idx_br_interest` colliding with the existing
`berth_recommendations.idx_br_interest`; renamed to
`idx_brr_interest` / `idx_brr_contract_file`).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

src/app/api/v1/expenses/export/pdf/route.ts

@@ -45,6 +45,7 @@ export const POST = withAuth(
               category: input.filter.category ?? null,
               paymentStatus: input.filter.paymentStatus ?? null,
               payer: input.filter.payer ?? null,
+              tripLabel: input.filter.tripLabel ?? null,
               includeArchived: input.filter.includeArchived ?? false,
             }
           : undefined,

src/app/api/v1/expenses/trip-labels/route.ts

@@ -0,0 +1,29 @@
+import { NextResponse } from 'next/server';
+
+import { withAuth, withPermission } from '@/lib/api/helpers';
+import { errorResponse } from '@/lib/errors';
+import { listTripLabels } from '@/lib/services/expenses';
+
+/**
+ * GET /api/v1/expenses/trip-labels?search=palm
+ *
+ * Returns the distinct trip-label values used in this port, ordered by
+ * most-recent expense date. Powers the autocomplete on the expense form
+ * + the trip filter on the list page so reps don't end up with
+ * "Palm Beach 2026" vs " palm beach 2026 " split across two groups in
+ * the PDF export.
+ *
+ * Permission: `expenses.view` — same gate as the list endpoint.
+ */
+export const GET = withAuth(
+  withPermission('expenses', 'view', async (req, ctx) => {
+    try {
+      const url = new URL(req.url);
+      const search = url.searchParams.get('search') ?? undefined;
+      const labels = await listTripLabels(ctx.portId, search);
+      return NextResponse.json({ data: labels });
+    } catch (error) {
+      return errorResponse(error);
+    }
+  }),
+);