Add persistent BANNER notice type for maintenance and outage info

[JamieRuderman]

Summary

• Add a BANNER notice type that renders as a non-dismissible bar pinned to the top of the app, intended for system maintenance and outage information.
• Query the previously-unused preview (short-form HTML) and until fields from the notices API and use them for banner copy and expiry.
• Exclude banners from the announcements list, the unread badge, and the full-screen announcement dialog.

Why

Maintenance and outage notices need to stay visible for the duration of the event. Dismissal is deliberately not offered — a user who dismisses and forgets is the one who files the support ticket the banner was meant to prevent.

Because there is no client-side escape hatch, the banner must reliably remove itself. That is handled server-side by Notice.visible(), which already filters on enabled, stage, language and the from/until window — so ops can expire or kill a banner without a client release.

Implementation notes

• preview instead of body. The schema already exposes a dedicated short-form "Preview HTML" field, which suits a single-line bar far better than the full body HTML. Falls back to title when preview is empty.
• until is re-checked client-side on every render, not in the memoized selector. The server already filters expired notices, but announcements is in the redux-persist whitelist, so an offline or failed fetch would otherwise leave an expired banner pinned with no way to dismiss it.
• Reuses the existing Notice component (severity="warning", fullWidth, solid). Omitting its optional onClose is what makes the bar non-dismissible.
• Multiple active banners stack. Showing only the newest could hide a second concurrent incident.
• Placed next to ViewAsBanner in App.tsx, matching the existing top-banner pattern.

⚠️ Requires an API change before it does anything

NoticeType in graphql-api does not yet include BANNER. Until it does, no notice can carry the type and this code renders nothing (it is inert, not broken).

The enum is stored as an int (GENERIC=0 … COMMUNICATION=4), so appending BANNER=5 is purely additive — no DB migration needed, the column is already int, and existing rows are not renumbered.

preview and until are already exposed as GraphQL fields, so querying them is safe today.

Validation

• npm run typecheck
• npm run build
• Not yet exercised end-to-end in the running app, since no notice can return type: BANNER until the API enum lands.

[aws-amplify-us-west-1]

This pull request is automatically being deployed by Amplify Hosting (learn more).

Access this pull request here: https://pr-1146.d20k671nqqv4kl.amplifyapp.com