Promote uat → main (PROD): GRO-2319 portal waitlist surfacing + seed (#207)

Co-authored-by: Flea Flicker <22+gb_flea@noreply.git.farh.net>
Co-committed-by: Flea Flicker <22+gb_flea@noreply.git.farh.net>

packages/db/src/seed.ts

@@ -837,12 +837,14 @@ async function seedUatGroomerLinkage(
  * a deterministic spread of appointments so the customer-portal StatusBadge
  * palette can be LIVE-observed (not just code-verified against the bundle).
  *
- * Scope is the subset of badge states reachable from the `appointment_status`
- * enum (`scheduled, confirmed, in_progress, completed, cancelled, no_show`) —
- * the portal's <StatusBadge> renders `appointment.status` verbatim. `pending`
- * and `waitlisted` are NOT valid appointment statuses and cannot be seeded; the
- * styled `no_show`→`no-show` badge fix and any pending/waitlisted derivation are
- * tracked separately in GRO-2319 (web). CTO-approved Option A on GRO-2313.
+ * `appointment_status` enum is (`scheduled, confirmed, in_progress, completed,
+ * cancelled, no_show`) — the portal's <StatusBadge> renders `appointment.status`
+ * verbatim. `pending` and `waitlisted` are NOT valid appointment statuses, so
+ * GRO-2319 derives them in the portal: `pending` from an upcoming appointment's
+ * `confirmationStatus` (the `scheduled` row below carries `pending`), and
+ * `waitlisted` from an ACTIVE `waitlist_entries` row (seeded at the end of this
+ * function) which `GET /api/portal/appointments` surfaces as a synthetic card.
+ * The `no_show`→`no-show` badge-key fix is the web side of GRO-2319.
  *
  *   - confirmed  → future startTime → renders as an Upcoming card (Confirmed badge)
  *   - scheduled  → future startTime → renders as an Upcoming card (Scheduled badge)
@@ -990,6 +992,44 @@ async function seedUatCustomerPortalAppointments(
   console.log(
     `✓ GRO-2311: seeded ${rows.length} portal StatusBadge appointments (confirmed/scheduled/cancelled/no_show) for UAT customer`,
   );
+
+  // GRO-2319 item 2: seed one ACTIVE waitlist entry so the portal's `waitlisted`
+  // card (surfaced by GET /api/portal/appointments) is live-observable. Unlike
+  // appointments, `waitlist_entries` is NOT truncated on the hourly reset, so we
+  // upsert by fixed id and REFRESH the preferred date to a future-relative value
+  // each reset — otherwise the date would go stale and the card would drop out of
+  // the Upcoming list. (The seeded `scheduled` appointment above already carries
+  // `confirmationStatus: "pending"`, which drives the live Pending badge.)
+  const WAITLIST_ENTRY_ID = "e0000001-0000-0000-0000-000000000001";
+  const pad2 = (n: number): string => String(n).padStart(2, "0");
+  const wlStart = at(7, 13); // 7 days out, 1pm — comfortably "upcoming"
+  const wlPreferredDate = `${wlStart.getFullYear()}-${pad2(wlStart.getMonth() + 1)}-${pad2(wlStart.getDate())}`;
+  const wlPreferredTime = `${pad2(wlStart.getHours())}:00:00`;
+
+  await db
+    .insert(schema.waitlistEntries)
+    .values({
+      id: WAITLIST_ENTRY_ID,
+      clientId: customerClientId,
+      petId: LINKED_PET_ID,
+      serviceId,
+      preferredDate: wlPreferredDate,
+      preferredTime: wlPreferredTime,
+      status: "active",
+    })
+    .onConflictDoUpdate({
+      target: schema.waitlistEntries.id,
+      set: {
+        preferredDate: wlPreferredDate,
+        preferredTime: wlPreferredTime,
+        status: "active",
+        updatedAt: new Date(),
+      },
+    });
+
+  console.log(
+    `✓ GRO-2319: seeded 1 active waitlist entry (${wlPreferredDate} ${wlPreferredTime}) for UAT customer portal Waitlisted card`,
+  );
 }
 
 // ── GRO-2225: deterministic route-optimization cohort ────────────────────────