feat(pipeline): 9→7 stage refactor + v1.1 hardening wave

Replaces the legacy 9-stage pipeline with 7 canonical stages
(enquiry → qualified → eoi → reservation → deposit_paid → contract →
nurturing) plus three doc sub-status columns (eoi_doc_status,
reservation_doc_status, contract_doc_status) that track sent/signed
within a single stage instead of branching it.

Schema (migration 0062):
- interests gains assigned_to, deposit_expected_amount/currency,
  three doc-status columns, two documenso-id columns, and
  date_reservation_signed.
- New tables: qualification_criteria (per-port admin-configurable),
  interest_qualifications (per-interest state), payments (deposit /
  balance / refund records keyed to interest + client).
- Default qualification criteria seeded for every existing port.
- Dummy-data UPDATEs collapse Sent/Signed pairs and 'completed' into
  the new stage + doc-status + outcome shape.

Migration 0063 adds interest_contact_log.voice_transcript and
template_used columns for v1.1-A/B (quick-template buttons + voice
transcription via Web Speech API).

v1.1 phase work bundled here:
- A/B: Quick-template buttons (Call / Visit / Email) + mic toggle on
       the contact-log compose dialog (useVoiceTranscription hook).
- C:   berth-rules-engine wraps state writes in pg_advisory_xact_lock
       with an idempotent re-read; emits rule_evaluated audit traces.
- D:   Documenso webhook: reservation/contract sub-status stamping
       moved out of the PDF-download try-block so a download failure
       no longer swallows the stamp. New integration test coverage.
- E:   /admin/qualification-criteria CRUD page + admin component.
- F:   default_new_interest_owner exposed in System Settings.
- G:   recentActivityCount + active_engagement deal-pulse signal
       surfaced as a chip on interests + hot-deals card.
- H:   interest_assigned notification on assignedTo change (skips
       self-assign, uses a dedupe key).

Plus the supporting components: AssignedToChip, DealPulseChip,
PaymentsSection, QualificationChecklist, MultiEoiChip,
SkipAheadBanner, WonStatusPanel, InterestBerthStatusBanner,
SupplementalInfoRequestButton, UserPicker.

Tests: 1370/1370 vitest pass (added deal-health unit suite +
expanded constants/validators/pipeline-transitions coverage). tsc
clean, eslint clean.

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

src/lib/services/search.service.ts

@@ -68,6 +68,8 @@ export interface ClientResult {
   matchedContactChannel: 'email' | 'phone' | 'whatsapp' | null;
   archivedAt: string | null;
   relatedVia?: RelatedVia | null;
+  /** Short label for which field matched ("name", "email", "phone", "trigram", "expansion"). Used by the dropdown to render "matched on X". */
+  matchedOn?: string | null;
 }
 
 export interface ResidentialClientResult {
@@ -451,13 +453,25 @@ async function searchClients(
     LIMIT ${limit}
   `);
 
-  return Array.from(rows).map((r) => ({
-    id: r.id,
-    fullName: r.full_name,
-    matchedContact: r.matched_value ?? null,
-    matchedContactChannel: r.matched_channel ?? null,
-    archivedAt: r.archived_at ? r.archived_at.toISOString() : null,
-  }));
+  return Array.from(rows).map((r) => {
+    // Tag the rank tier we picked back as a human-readable label so the
+    // dropdown can render "matched on name" / "matched on email" without
+    // the UI re-doing the comparison. Mirrors the CASE in `rank` above.
+    let matchedOn: string | null = null;
+    if (r.rank >= 80) matchedOn = 'name';
+    else if (r.rank >= 70) matchedOn = 'name';
+    else if (r.rank >= 60) matchedOn = r.matched_channel ?? 'contact';
+    else if (r.rank >= 55) matchedOn = 'phone';
+    else if (r.rank >= 30) matchedOn = 'similar name';
+    return {
+      id: r.id,
+      fullName: r.full_name,
+      matchedContact: r.matched_value ?? null,
+      matchedContactChannel: r.matched_channel ?? null,
+      archivedAt: r.archived_at ? r.archived_at.toISOString() : null,
+      matchedOn,
+    };
+  });
 }
 
 async function searchResidentialClients(
@@ -1870,17 +1884,38 @@ export async function search(
   // who search "A10" see the linked interests/clients/yachts/companies
   // surface alongside the berth. See `expandGraph` docstring for the
   // relationship map and per-bucket caps.
-  const expanded = await expandGraph(
-    portId,
-    {
-      berthIds: berths.map((b) => b.id),
-      interestIds: interests.map((i) => i.id),
-      clientIds: clients.map((c) => c.id),
-      yachtIds: yachts.map((y) => y.id),
-      companyIds: companies.map((c) => c.id),
-    },
-    limit,
-  );
+  //
+  // Latency optimization: when every relationship-bearing bucket already
+  // has the maximum number of direct matches the dropdown will render,
+  // graph expansion only adds rows that get truncated downstream — skip
+  // the (cross-table-heavy) expansion query entirely. Saves the biggest
+  // single SQL call in the search path on common-term queries.
+  const allBucketsFull =
+    clients.length >= limit &&
+    yachts.length >= limit &&
+    companies.length >= limit &&
+    interests.length >= limit &&
+    berths.length >= limit;
+
+  const expanded = allBucketsFull
+    ? {
+        interests: [] as InterestResult[],
+        clients: [] as ClientResult[],
+        yachts: [] as YachtResult[],
+        companies: [] as CompanyResult[],
+        berths: [] as BerthResult[],
+      }
+    : await expandGraph(
+        portId,
+        {
+          berthIds: berths.map((b) => b.id),
+          interestIds: interests.map((i) => i.id),
+          clientIds: clients.map((c) => c.id),
+          yachtIds: yachts.map((y) => y.id),
+          companyIds: companies.map((c) => c.id),
+        },
+        limit,
+      );
 
   const apply = <T extends { id: string }>(rows: T[]) =>
     applyAffinity(rows, opts.recentlyTouchedIds);