fix(pipeline-refactor): purge stale 9-stage name references

Audit of every '*_sent' / '*_signed' / 'in_communication' / 'details_sent'
/ 'deposit_10pct' / 'completed' literal under src/ caught four genuinely
broken sites that migration 0062 collapsed away but the runtime code
never followed through on:

1. alert-rules.ts: `interest.stale` matched 'details_sent' /
   'in_communication' / 'eoi_sent' — none of which exist post-migration.
   The alert never fired. Updated to the new mid-funnel canon (enquiry /
   qualified / nurturing).

2. berth-recommender.service.ts: TWO copies of the same stage-rank CASE
   (one for active history, one for fallthrough scoring) referenced the
   full legacy 8-stage ladder. Every WHEN missed → MAX(...) returned 0 →
   tier-ladder + heat-score logic collapsed silently. Rebuilt both
   against the 7-stage canon mirroring getHotDeals.

3. interests.service.ts: clearInterestOutcome reopen default was the
   dead 'in_communication'. Switched to 'qualified' (closest analog;
   rep can still override via data.reopenStage). Pre-fix, any reopened
   deal fell through safeStage() to 'enquiry'.

4. report-generators.ts: revenue-PDF "total completed" filter
   intersected pipeline_stage='completed' AND outcome='won'. The stage
   filter is redundant today (setInterestOutcome always writes
   'completed' for terminal outcomes) and is brittle to the upcoming
   sentinel-stage cleanup. Dropped the stage filter — outcome='won' is
   the canonical money-changed-hands signal.

Follow-up flagged: setInterestOutcome still writes pipeline_stage =
'completed' as a sentinel, which is non-canonical under the new 7-stage
type (PIPELINE_STAGES doesn't include 'completed'). Migration 0062's
intent is `outcome` carries terminal state forward; pipeline_stage stays
in-canon. Cleaning up requires sweeping every consumer of
pipeline_stage='completed' as a terminal marker — separate commit.

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

src/lib/services/report-generators.ts

@@ -127,10 +127,12 @@ export async function fetchRevenueData(
   }
 
   // Total revenue from WON interests only. Reporting audit caught the
-  // gap: setInterestOutcome forces pipelineStage='completed' for lost
-  // AND cancelled outcomes too, so filtering by stage alone counted
-  // those toward "TOTAL COMPLETED REVENUE". The outcome='won' filter is
-  // the canonical money-changed-hands signal.
+  // `outcome='won'` is the canonical money-changed-hands signal — won
+  // deals can technically be set from any pipeline stage, and the legacy
+  // belt-and-suspenders `pipeline_stage='completed'` filter is brittle to
+  // future cleanup of the 'completed' sentinel-stage convention (see
+  // PRE-DEPLOY-PLAN follow-ups). The outcome filter alone catches every
+  // won deal regardless of the stage it closed at.
   const completedRevenue = await db
     .select({ total: sum(berths.price) })
     .from(interests)
@@ -140,12 +142,7 @@ export async function fetchRevenueData(
     )
     .leftJoin(berths, eq(interestBerths.berthId, berths.id))
     .where(
-      and(
-        eq(interests.portId, portId),
-        eq(interests.pipelineStage, 'completed'),
-        eq(interests.outcome, 'won'),
-        isNull(interests.archivedAt),
-      ),
+      and(eq(interests.portId, portId), eq(interests.outcome, 'won'), isNull(interests.archivedAt)),
     );
 
   return {