refactor(interests): migrate callers to interest_berths junction + drop berth_id

Phase 2b of the berth-recommender refactor (plan §3.4). Every caller of
the legacy `interests.berth_id` column now reads / writes through the
`interest_berths` junction via the helper service introduced in Phase 2a;
the column itself is dropped in a final migration.

Service-layer changes
- interests.service: filter `?berthId=X` becomes EXISTS-against-junction;
  list enrichment uses `getPrimaryBerthsForInterests`; create/update/
  linkBerth/unlinkBerth all dispatch through the junction helpers, with
  createInterest's row insert + junction write sharing a single transaction.
- clients / dashboard / report-generators / search: leftJoin chains pivot
  through `interest_berths` filtered by `is_primary=true`.
- eoi-context / document-templates / berth-rules-engine / portal /
  record-export / queue worker: read primary via `getPrimaryBerth(...)`.
- interest-scoring: berthLinked is now derived from any junction row count.
- dedup/migration-apply + public interest route: write a primary junction
  row alongside the interest insert when a berth is provided.

API contract preserved: list/detail responses still emit `berthId` and
`berthMooringNumber`, derived from the primary junction row, so frontend
consumers (interest-form, interest-detail-header) need no changes.

Schema + migration
- Drop `interestsRelations.berth` and `idx_interests_berth`.
- Replace `berthsRelations.interests` with `interestBerths`.
- Migration 0029_puzzling_romulus drops `interests.berth_id` + the index.
- Tests that previously inserted `interests.berthId` now seed a primary
  junction row alongside the interest.

Verified: vitest 995 passing (1 unrelated pre-existing flake in
maintenance-cleanup.test.ts), tsc clean.

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

src/lib/services/interest-scoring.service.ts

@@ -2,7 +2,7 @@ import { and, count, eq, gte, isNull } from 'drizzle-orm';
 
 import { db } from '@/lib/db';
 import { redis } from '@/lib/redis';
-import { interests, interestNotes } from '@/lib/db/schema/interests';
+import { interests, interestBerths, interestNotes } from '@/lib/db/schema/interests';
 import { reminders } from '@/lib/db/schema/operations';
 import { emailThreads } from '@/lib/db/schema/email';
 import { logger } from '@/lib/logger';
@@ -134,7 +134,7 @@ export async function calculateInterestScore(
   // 4. Engagement - notes, emails, reminders in last 30 days
   const thirtyDaysAgo = new Date(Date.now() - 30 * 24 * 60 * 60 * 1000);
 
-  const [notesResult, remindersResult, emailResult] = await Promise.all([
+  const [notesResult, remindersResult, emailResult, berthLinkResult] = await Promise.all([
     db
       .select({ value: count() })
       .from(interestNotes)
@@ -161,6 +161,13 @@ export async function calculateInterestScore(
           gte(emailThreads.lastMessageAt, thirtyDaysAgo),
         ),
       ),
+    // Plan §3.4: any junction row counts as "berth linked", not just the
+    // primary - the score awards engagement for an interest that has *any*
+    // berth association at all.
+    db
+      .select({ value: count() })
+      .from(interestBerths)
+      .where(eq(interestBerths.interestId, interestId)),
   ]);
 
   const notesCount = notesResult[0]?.value ?? 0;
@@ -172,8 +179,8 @@ export async function calculateInterestScore(
   const remindersScore = Math.min(remindersCount * 10, 20);
   const engagement = Math.min(notesScore + emailScore + remindersScore, 100);
 
-  // 5. Berth linked
-  const berthLinked = interest.berthId != null ? 25 : 0;
+  // 5. Berth linked - true when the interest has at least one junction row.
+  const berthLinked = (berthLinkResult[0]?.value ?? 0) > 0 ? 25 : 0;
 
   // ── Normalise: max raw = 100+100+100+100+25 = 425 → /425 * 100 ──
   const RAW_MAX = 425;