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/components/interests/multi-eoi-chip.tsx

@@ -0,0 +1,47 @@
+'use client';
+
+import { useQuery } from '@tanstack/react-query';
+import { FileSignature } from 'lucide-react';
+
+import { apiFetch } from '@/lib/api/client';
+
+interface DocumentRow {
+  id: string;
+  documentType: string;
+  status: string;
+  archivedAt: string | null;
+}
+
+interface DocumentsResponse {
+  data: DocumentRow[];
+}
+
+/**
+ * Subtle chip that surfaces when an interest has multiple in-flight EOI
+ * documents (status != voided, not archived). Per product direction we
+ * intentionally allow multi-EOI cases (sometimes a deal really does need
+ * a second EOI for a different berth combo), but the rep should see the
+ * conflict at a glance so they don't accidentally re-send.
+ */
+export function MultiEoiChip({ interestId }: { interestId: string }) {
+  const { data } = useQuery<DocumentsResponse>({
+    queryKey: ['documents', { interestId, documentType: 'eoi' }],
+    queryFn: () => apiFetch(`/api/v1/documents?interestId=${interestId}&documentType=eoi`),
+    staleTime: 60_000,
+  });
+
+  const inflight = (data?.data ?? []).filter(
+    (d) => !d.archivedAt && d.status !== 'voided' && d.status !== 'declined',
+  );
+  if (inflight.length < 2) return null;
+
+  return (
+    <span
+      title={`This interest has ${inflight.length} in-flight EOI documents — review on the EOI tab.`}
+      className="inline-flex items-center gap-1 rounded-full border border-amber-200 bg-amber-50 px-2 py-0.5 text-[11px] font-medium text-amber-800"
+    >
+      <FileSignature className="size-3" aria-hidden />
+      {inflight.length} EOIs
+    </span>
+  );
+}