refactor(sales): consolidate pipeline stages + wire EOI auto-advance

The 8→9 stage refresh from earlier today only updated constants.ts and the DB —
20 component/service files still hardcoded the old enum, leaving labels blank,
filter dropdowns wrong, kanban columns mismatched, and the analytics funnel
silently dropping new-stage rows. The platform also never advanced
pipelineStage on EOI lifecycle events: documents.service.ts wrote eoiStatus
but left the user-visible stage stuck.

This commit closes both gaps:

  1. Single source of truth in src/lib/constants.ts — adds STAGE_LABELS,
     STAGE_BADGE, STAGE_DOT, STAGE_WEIGHTS, STAGE_TRANSITIONS plus
     stageLabel / stageBadgeClass / stageDotClass / safeStage /
     canTransitionStage helpers. components/clients/pipeline-constants.ts
     becomes a re-export shim so existing imports keep working.

  2. 18 stale-enum surfaces migrated — interest list (table, card, filters,
     form, stage picker), pipeline board, client card, berth interests tab,
     portal client interests page, dashboard pipeline / funnel / revenue-
     forecast charts, settings pipeline_weights default, dashboard.service
     weights, analytics.service funnel stages, alert-rules stale-interest
     filter, interest-scoring stage rank.

  3. Documents tab wired into interest detail — replaced the placeholder in
     interest-tabs.tsx with InterestDocumentsTab + InterestFilesTab so the
     EOI launcher is back where salespeople work.

  4. Auto-advance — new advanceStageIfBehind() in interests.service.ts
     (forward-only, no-op if interest is already past the target). Called
     from documents.service.ts on send (→ eoi_sent), Documenso completed
     webhook (→ eoi_signed), and manual signed-EOI upload (→ eoi_signed).

  5. Transition guard — canTransitionStage() blocks egregious skips
     (e.g. completed → open, open → contract_signed). Enforced in
     changeInterestStage before the DB write.

Tests updated to reflect the 9-stage model. tsc clean, vitest 832/832,
ESLint clean on every file touched.

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

tests/unit/constants.test.ts

@@ -1,13 +1,9 @@
 import { describe, it, expect } from 'vitest';
-import {
-  PIPELINE_STAGES,
-  BERTH_STATUSES,
-  NOTIFICATION_TYPES,
-} from '@/lib/constants';
+import { PIPELINE_STAGES, BERTH_STATUSES, NOTIFICATION_TYPES } from '@/lib/constants';
 
 describe('PIPELINE_STAGES', () => {
-  it('has exactly 8 entries', () => {
-    expect(PIPELINE_STAGES).toHaveLength(8);
+  it('has exactly 9 entries', () => {
+    expect(PIPELINE_STAGES).toHaveLength(9);
   });
 
   it('starts with "open"', () => {
@@ -23,25 +19,18 @@ describe('PIPELINE_STAGES', () => {
       'open',
       'details_sent',
       'in_communication',
-      'visited',
-      'signed_eoi_nda',
+      'eoi_sent',
+      'eoi_signed',
       'deposit_10pct',
-      'contract',
+      'contract_sent',
+      'contract_signed',
       'completed',
     ]);
   });
 
-  it('is a readonly (frozen) tuple — cannot be mutated at runtime', () => {
-    expect(() => {
-      // TypeScript readonly doesn't prevent runtime mutation of `as const` arrays,
-      // but they are not Object.frozen. The important thing is the `as const` means
-      // the type system protects it. We verify immutability via the TypeScript type
-      // and check the array is not a plain mutable array.
-      const arr = PIPELINE_STAGES as unknown as string[];
-      // Attempting splice on a readonly const-asserted array at runtime won't throw
-      // but the values should be what we defined.
-      expect(arr).toHaveLength(8);
-    }).not.toThrow();
+  it('is a readonly tuple — type-level immutability via `as const`', () => {
+    const arr = PIPELINE_STAGES as unknown as string[];
+    expect(arr).toHaveLength(9);
   });
 
   it('has no duplicate entries', () => {