sec: lock down 5 cross-tenant FK gaps from fifth-pass review

1. HIGH — reminders.create/updateReminder accepted clientId/interestId/
   berthId from the body and persisted them with no port check; getReminder
   then hydrated the row via Drizzle relations (no port filter on the
   join), so a port-A user with reminders:create could exfiltrate any
   port-B client/interest/berth row by guessing its UUID. New
   assertReminderFksInPort gates create + update.

2. HIGH — listRecommendations(interestId, _portId) discarded portId
   entirely; the route GET /api/v1/interests/[id]/recommendations
   forwarded the URL id straight through. A port-A user with
   interests:view could read any other tenant's recommended berths
   (mooring numbers, dimensions, status). Service now verifies the
   interest belongs to portId and joins berths filtered by port.

3. HIGH — Berth waiting list. The PATCH route did not pre-check that
   the berth belonged to ctx.portId — a port-A user with
   manage_waiting_list could reorder a port-B berth's queue. Separately,
   updateWaitingList accepted arbitrary entries[].clientId and inserted
   them without verifying tenancy, polluting the table with foreign-port
   FKs. Both gaps closed.

4. MEDIUM — setEntityTags (clients/companies/yachts/interests/berths)
   accepted any tagId and inserted into the join table. The tags table
   is per-port but the join only carries a single-column FK. The
   downstream getById join `tags ON join.tag_id = tags.id` has no port
   filter, so a foreign tag's name + color render in the requesting port.
   Helper now batch-validates tagIds belong to portId before insert.

5. MEDIUM — /api/v1/custom-fields/[entityId] PUT had no withPermission
   gate (any role, including viewer, could write) and didn't validate
   that the URL entityId pointed at a port-scoped entity of the field
   definition's entityType. Route now uses
   withPermission('clients','view'/'edit',…); service validates the
   entityId per resolved entityType (client/interest/berth/yacht/company)
   against portId.

Test mocks updated to cover the new entity-port-scope check.
818 vitest tests pass.

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

src/lib/services/recommendations.ts

@@ -147,7 +147,16 @@ export async function generateRecommendations(interestId: string, portId: string
 
 // ─── List Recommendations ─────────────────────────────────────────────────────
 
-export async function listRecommendations(interestId: string, _portId: string) {
+export async function listRecommendations(interestId: string, portId: string) {
+  // Verify the interest belongs to the caller's port. Without this gate,
+  // any user with `interests:view` could pass a foreign-port interestId
+  // and receive that tenant's recommended berths (mooring numbers,
+  // dimensions, status — operational data they should not see).
+  const interest = await db.query.interests.findFirst({
+    where: and(eq(interests.id, interestId), eq(interests.portId, portId)),
+  });
+  if (!interest) throw new NotFoundError('Interest');
+
   const rows = await db
     .select({
       id: berthRecommendations.id,
@@ -167,7 +176,7 @@ export async function listRecommendations(interestId: string, _portId: string) {
     })
     .from(berthRecommendations)
     .innerJoin(berths, eq(berthRecommendations.berthId, berths.id))
-    .where(eq(berthRecommendations.interestId, interestId))
+    .where(and(eq(berthRecommendations.interestId, interestId), eq(berths.portId, portId)))
     .orderBy(berthRecommendations.matchScore);
 
   return rows.reverse(); // highest score first