feat(GRO-2319): live-render full StatusBadge palette in portal

- StatusBadge normalizes underscore status keys (no_show → no-show) so a
  DB-sourced no_show appointment renders the styled "No-show" badge instead
  of a raw gray label (item 1).
- deriveDisplayStatus derives a Pending badge for an upcoming appointment
  whose confirmationStatus is pending, and Waitlisted for synthetic waitlist
  entries (item 2, CMPO-approved on GRO-2326/GRO-2328).
- AppointmentCard renders waitlist-backed entries with a muted dashed-border
  card + "You're on the waitlist…" subtext, and hides the confirm/notes/
  reschedule/cancel actions (a waitlist entry is not a booked appointment).
- Tests for normalizeStatusKey, deriveDisplayStatus, and the No-show badge.
- UAT_PLAYBOOK.md §5.12f added for the now-live palette states.

Co-Authored-By: Paperclip <noreply@paperclip.ing>

UAT_PLAYBOOK.md

@@ -217,6 +217,25 @@ export const { signIn, signOut, useSession, changePassword } = authClient;
 | TC-WEB-5.12.16 | Badge status from data | Compare badge label to appointment.status field | Badge label matches the API appointment status exactly |
 | TC-WEB-5.12.17 | Unknown status fallback | Render badge with unknown status value | Badge renders with the raw status string as label and fallback CSS class |
 
+#### 5.12f Live StatusBadge palette — no-show / pending / waitlisted (GRO-2319)
+
+These cases exercise the full StatusBadge palette as it is now produced live by
+the seeded UAT customer (`uat-customer@groombook.dev`), not just unit-rendered.
+
+| # | Scenario | Steps | Expected |
+|---|----------|-------|----------|
+| TC-WEB-5.12.26 | No-show badge (item 1) | Sign in as `uat-customer@groombook.dev`, open `Appointments` → **Past** tab, find the seeded `no_show` appointment | A styled yellow **"No-show"** badge renders (`bg-yellow-100 text-yellow-700`) — **not** a raw gray `no_show` label. The DB `no_show` (underscore) status is normalized to the `no-show` palette key. |
+| TC-WEB-5.12.27 | Pending derivation (item 2) | On the **Upcoming** tab, find the seeded upcoming appointment whose `confirmationStatus` is `pending` (groomer-unconfirmed) | The card's top-row badge reads amber **"Pending"** (derived from `confirmationStatus`), even though the raw appointment status is `scheduled`. |
+| TC-WEB-5.12.28 | Confirmed not overridden | On the **Upcoming** tab, find the seeded confirmed appointment (`confirmationStatus = confirmed`) | Badge still reads green **"Confirmed"** — the pending derivation does not override a confirmed appointment. |
+| TC-WEB-5.12.29 | Waitlisted card (item 2) | On the **Upcoming** tab, find the seeded waitlist entry for the customer | A card renders with a blue **"Waitlisted"** badge, a **dashed muted border**, and the subtext _"You're on the waitlist — we'll let you know if a spot opens."_ The Confirm / Reschedule / Cancel / Notes actions are **not** shown for this entry (it is not a booked appointment). |
+
+> **GRO-2319 note:** the DB `appointment_status` enum cannot represent `pending`
+> or `waitlisted`, so those badges are derived in the portal: `pending` from an
+> upcoming appointment's `confirmationStatus`, and `waitlisted` from active
+> `waitlist_entries` surfaced by `GET /api/portal/appointments` as synthetic
+> cards. The `no_show` → `no-show` key normalization fixes the cosmetic badge
+> mismatch (item 1).
+
 #### 5.12d Appointment API Shape Normalization (GRO-2180)
 
 | # | Scenario | Steps | Expected |