System alert header reports the unacknowledged count for only the loaded page

## Problem

The System Alerts page header reports "N unacknowledged alerts", but the count is derived only from the rows currently loaded on the page, not from the filtered result set.

The page supports level, domain, instance, transition, label, time-range, and suppression filters, and fetches alerts through server-side pagination. During an incident the displayed number can therefore understate the real amount of outstanding operator work, and it does not match the pagination total either.

## Current behavior and reproduction

1. Open **Ops > System Alerts** on an installation where a filter (for example level = error) matches more than 20 alerts — the fixed page size.
2. Note the header subtitle reports the unacknowledged count.
3. Compare it with the pagination total for the same filter: the header shows at most 20 (or fewer on the last page), while the filter actually matches more unacknowledged alerts.

`web/src/pages/ops/systemAlerts.tsx` (around line 240):

```ts
const unackCount = alerts.filter((a) => !a.acknowledged).length;
```

`alerts` contains only the current page, while the same filters are also sent to `GET /api/system-alerts/page`, which returns a result-set-wide `total`. The backend currently exposes only the paged feed; there is no aggregate endpoint returning total and unacknowledged counts for a filter.

## Proposed behavior

- Add `GET /api/system-alerts/summary` returning `total` and `unacknowledged` for the current filter.
- Apply exactly the same filters as the paged feed: level, domain, instance, transition, label key/value, time range, and notification-suppressed flag.
- Keep the existing validation semantics for inverted time ranges and incomplete label filters.
- Compute both counters in one repository aggregation query rather than two requests.
- Load the summary together with the alert page and use its `unacknowledged` value in the header.
- Keep a page-local fallback only if the summary request fails.

## Acceptance criteria

- [ ] `GET /api/system-alerts/summary` returns `{total, unacknowledged}`.
- [ ] All paged-feed filters (level, domain, instanceId, transition, labelKey/labelValue, from/to, notificationSuppressed) are accepted and applied.
- [ ] Inverted time ranges and half-specified label filters are rejected like the paged endpoint.
- [ ] Both counters come from one repository aggregation query.
- [ ] The header uses the summary value and falls back to page-local counting only on summary failure.
- [ ] Backend tests cover filter forwarding, validation, and aggregation; frontend tests cover header usage and fallback.

## Importance

Should-have. The unacknowledged count is used to judge outstanding operator work during an incident; a page-local count hides the true backlog and disagrees with the pagination total shown on the same page.

## Duplicate check

Searched open and closed issues/PRs for `system alert summary`, `unacknowledged count`, `result-set-wide alert count`, `system alert header count`. No existing issue or PR addresses the page-local unacknowledged count.

Start in web/src/pages/ops/systemAlerts.tsx around the page-local unacknowledged count, then trace the existing GET /api/system-alerts/page handler and repository query. Use the existing filter and validation behavior as the reference; done means the summary returns both counters, backend and frontend tests cover the listed cases, and the header uses the summary with the stated fallback.

Written by the indexing model from the issue text.