UI: implement Alerts and alert groups with v3alpha services

Parent: #5451
API dependencies: #5479, #5481, #5483

Summary

Implement the complete Alerts experience using generated alert.v3alpha.AlertService and receiver.v3alpha.ReceiverService clients, with no API v2 fallback.

Alert and group display

• Render paginated natural alert groups with stable group identity, receiver metadata, group labels, route labels, muted metadata, and alert counts.
• Provide accessible per-group and expand/collapse-all controls while avoiding rendering collapsed alert bodies.
• Render alert labels, annotations, starts/ends/relative time, generator links, source/deep links, and silenced/inhibited/muted/unprocessed state.
• Provide links to existing silences and a Silence action that pre-populates the new Silence form from alert labels.
• Preserve the expand-all preference.

Filtering and navigation

• Keep matcher sets, state toggles, receiver filters, receiver-label filters, grouping, and pagination in the URL so links reproduce the view.
• Support active, silenced, inhibited, muted, and unprocessed filters with the exact service semantics.
• Use ReceiverService for deterministic receiver discovery and OR-of-AND receiver-label filtering, including equality, inequality, regex, negated regex, and missing-label behavior.
• Preserve matcher escaping and UTF-8 label-name behavior.
• Provide loading, empty, unavailable, partial-result, pagination, manual-refresh, and structured-error states.

Custom grouping contract requirement

The Elm UI supports user-selected grouping labels. Client-side grouping of one paginated ListAlerts page would be incorrect.

Before the AlertService proto freezes, resolve one of the following:

1. Add a server-side requested grouping contract, such as group_by, to ListAlertGroups; or
2. Obtain an explicit maintainer-approved parity exception and document the removed behavior.

The UI must not fetch an unbounded complete alert list merely to reproduce custom grouping.

Existing work

Review #5031 for reusable presentation and time utilities. Do not retain its API v2 datasource, direct filter-string interpolation, unstable keys, stale query-cache behavior, or the copied pre-Mantine-9 Accordion implementation. Prefer Mantine 9's maintained primitives.

Acceptance criteria

• Natural alert groups, receivers, group/route labels, counts, statuses, annotations, times, links, and Silence actions render from generated v3alpha messages.
• Shared URLs reproduce all filters, grouping, and pagination state.
• Matcher and receiver filters correctly handle escaping, regex operators, missing labels, and UTF-8 names.
• Custom grouping is server-supported or has a documented maintainer-approved parity exception.
• Query pagination is deterministic and invalid tokens/partial results surface clearly.
• Collapsed groups do not render all alert bodies.
• Large datasets meet measured rendering and interaction targets; use windowing/virtualization when measurement requires it.
• /ui/ redirects to /ui/alerts after this page is complete.
• No API v2 calls or handwritten alert/receiver wire models remain.
• Component and real-server tests cover filters, grouping, pagination, errors, route prefixes, and alert-to-silence links.

Dependencies and related work

• Connect data layer: #5487.
• Application shell/settings: #5488.
• Shared contracts and pagination: #5479.
• Unary AlertService implementation: #5481.
• ReceiverService: #5483.
• Silence form integration is completed by the Silence UI child but does not block read-only Alerts delivery.
• Live automatic updates are tracked separately and relate to #524.

Likely code areas

• ui/mantine-ui/src/pages/Alerts.page.tsx
• new alert/group/filter/pagination components and tests
• generated alert/receiver query adapters
• replacement/removal of ui/mantine-ui/src/data/groups.ts