refactor(interests): drop pipelineStage='completed' sentinel convention

`outcome` is the canonical terminal-state signal. Pre-2026-05-14
`setInterestOutcome` also forced `pipelineStage='completed'` (a value
outside the 7-stage canon) which:

- broke `safeStage()` (silently coerced to 'enquiry' downstream)
- prevented analytics from answering "what stage was the deal at when
  it closed?" because every closed deal looked identical
- forced belt-and-suspenders filters everywhere ('outcome=won' AND
  'pipeline_stage=completed') that became redundant after migration 0062

Changes:

- `setInterestOutcome` no longer touches pipelineStage. Deal stays at
  whatever stage it was on when the outcome was recorded; outcome is
  the terminal signal. Audit log + websocket emit now carry
  `stageAtOutcome` instead of the stale `oldStage`.

- `clearInterestOutcome` smarter reopen-stage logic: if current stage
  is the legacy 'completed' sentinel (pre-existing rows from before
  this commit), default to 'qualified'. Otherwise preserve the stage
  the deal was at, so reopening drops the rep back where they were.
  Explicit data.reopenStage still wins.

- `/api/v1/admin/dashboard-stats` route reworked: per-stage breakdown
  now filters `outcome IS NULL` (only active rows count per stage);
  `closedTotal` derives from a new `outcome IS NOT NULL` count query;
  `completed30d` switches from `pipelineStage='completed' AND updatedAt`
  to `outcome IS NOT NULL AND outcomeAt` (avoids long-closed deals
  leaking into the window on unrelated edits).

- `berth-interests-tab.tsx` "active" filter switches from
  `pipelineStage !== 'completed'` to `!outcome && !archivedAt` — the
  legacy check stopped matching post-refactor.

- Socket event type `interest:outcomeSet` renames `oldStage` →
  `stageAtOutcome` with a doc-comment explaining the semantics shift.

PIPELINE_STAGES canon is now the only valid pipeline_stage value range
for newly-set outcomes. Legacy rows still carry 'completed' until they
naturally churn through reopen + re-close, at which point they enter
the new convention.

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

src/app/api/v1/admin/dashboard-stats/route.ts

@@ -1,5 +1,5 @@
 import { NextResponse } from 'next/server';
-import { and, eq, isNull, gte, sql } from 'drizzle-orm';
+import { and, eq, isNotNull, isNull, gte, sql } from 'drizzle-orm';
 
 import { withAuth, withPermission } from '@/lib/api/helpers';
 import { db } from '@/lib/db';
@@ -18,13 +18,26 @@ export const GET = withAuth(
       const thirtyDaysAgo = new Date(Date.now() - 30 * 24 * 60 * 60 * 1000);
 
       const [pipelineRows, berthStatusRows, totals, recent] = await Promise.all([
+        // Only active interests count toward per-stage breakdowns;
+        // terminal (outcome-set) interests are tracked separately via
+        // `closedTotal` below. Pre-2026-05-14 cleanup, terminal rows
+        // were grouped under the sentinel pipeline_stage='completed'
+        // bucket; the new convention leaves the stage where it was
+        // when the outcome was set, so we must filter by `outcome IS
+        // NULL` explicitly to keep the kanban breakdown honest.
         db
           .select({
             stage: interests.pipelineStage,
             count: sql<number>`count(*)::int`,
           })
           .from(interests)
-          .where(and(eq(interests.portId, portId), isNull(interests.archivedAt)))
+          .where(
+            and(
+              eq(interests.portId, portId),
+              isNull(interests.archivedAt),
+              isNull(interests.outcome),
+            ),
+          )
           .groupBy(interests.pipelineStage),
 
         db
@@ -49,6 +62,18 @@ export const GET = withAuth(
             .select({ count: sql<number>`count(*)::int` })
             .from(berths)
             .where(eq(berths.portId, portId)),
+          // closedTotal: all-time count of terminal (outcome-set)
+          // non-archived interests. Drives the conversion-rate tile.
+          db
+            .select({ count: sql<number>`count(*)::int` })
+            .from(interests)
+            .where(
+              and(
+                eq(interests.portId, portId),
+                isNull(interests.archivedAt),
+                isNotNull(interests.outcome),
+              ),
+            ),
         ]),
 
         Promise.all([
@@ -61,14 +86,18 @@ export const GET = withAuth(
                 gte(websiteSubmissions.receivedAt, sevenDaysAgo),
               ),
             ),
+          // "completed30d" = interests that hit a terminal outcome in
+          // the last 30 days (any outcome — won, lost, or cancelled).
+          // Use `outcome_at` not `updated_at` so unrelated edits to a
+          // long-closed deal don't drag it back into the window.
           db
             .select({ count: sql<number>`count(*)::int` })
             .from(interests)
             .where(
               and(
                 eq(interests.portId, portId),
-                eq(interests.pipelineStage, 'completed'),
-                gte(interests.updatedAt, thirtyDaysAgo),
+                isNotNull(interests.outcome),
+                gte(interests.outcomeAt, thirtyDaysAgo),
               ),
             ),
         ]),
@@ -90,10 +119,10 @@ export const GET = withAuth(
       const totalClients = totals[0][0]?.count ?? 0;
       const totalInterests = totals[1][0]?.count ?? 0;
       const totalBerths = totals[2][0]?.count ?? 0;
+      const closedTotal = totals[3][0]?.count ?? 0;
       const newInquiries7d = recent[0][0]?.count ?? 0;
       const completed30d = recent[1][0]?.count ?? 0;
 
-      const closedTotal = pipeline['completed'] ?? 0;
       const openTotal = totalInterests - closedTotal;
       const conversionPct =
         totalInterests > 0 ? Math.round((closedTotal / totalInterests) * 100) : 0;