Problem: NotificationPortlet coverage was just two structural smoke
tests in web-components.spec.ts (icon attached, dropdown attached).
Neither asserted that the API actually returned data or that the
portlet rendered any specific entries — so the live JJWT
runtime-classpath bug, where /api/v2 was returning 403 and the
components rendered empty, slipped through coverage entirely.

Goal: lock in the real end-to-end happy path (demo notifications
flow API → web component → DOM) plus the negative auth path, so the
JJWT regression cannot recur silently.

Changes:
- new tests/ux/portlets/notifications.spec.ts with three tests —
  * notification-list portlet renders demo entries: asserts the
    expected demo titles (Room Available, Bike License Ticket Was
    Issued, Past Due Book, Math 101) reach the rendered DOM. If
    /api/v2 starts 403'ing again, none of these will appear and
    this test fails immediately.
  * notification-icon web component shows a badge with a count:
    confirms the icon mounts as a custom element and renders a
    numeric unread badge for an authenticated student.
  * API rejects missing or malformed bearer tokens: negative
    guard. With no Authorization header → 403; with a junk JWT →
    403. This is the security half of the regression guard — the
    happy path landing on 200 only matters if the security filter
    is still enforcing.

Notes: the JJWT runtime-classpath bug that broke the API is fixed
in uPortal-Project/NotificationPortlet#695. The above tests
verified the fix end-to-end. The expected-titles list is the
intersection of the two demo response files configured via
DemoNotificationService.locations in etc/portal/notification.properties.

Removed an earlier draft `API returns demo notifications` test
that listened on page.on("response") — it was order-dependent in
the full suite (the listener attached after login may or may not
catch the first /api/v2 fetch), and the DOM-level
"renders demo entries" test already covers the same regression
without that race.

Problem: this branch has been carrying tests and overlay seeds that
depend on three companion fixes published over the last few days
(uPortal Bootstrap dedupe, CalendarPortlet template-sigil leak,
NotificationPortlet jjwt runtime classpath). Until those landed on
Maven Central, CI couldn't go green here even though every spec
passed locally against the locally-built SNAPSHOTs.

Goal: consume the published GA versions so PR uPortal-Project#692 lights up green
and is ready to merge.

Changes:
- uPortalVersion 5.17.4 → 5.17.5 (picks up
  uPortal-Project/uPortal#2980 — Bootstrap 5 include de-dup in the
  respondr skin, fixes silently-broken Options menus / favorites /
  rate-portlet across the dashboard)
- calendarPortletVersion 2.7.2 → 2.7.3 (picks up
  uPortal-Project/CalendarPortlet#404 — Underscore template
  settings override per call, fixes the events column rendering raw
  template source instead of event entries)
- notificationPortletVersion 4.8.3 → 4.8.4 (picks up
  uPortal-Project/NotificationPortlet#695 — pin jjwt-impl +
  jjwt-jackson at runtime, fixes /api/v2 silently 403'ing and the
  notification web components rendering empty)

Notes: locally redeployed the three webapps from Maven Central
artifacts and ran the Playwright suite three times in a row —
117/117 each pass — to confirm the published versions match what we
were testing against the SNAPSHOTs.