Alert rule counters mix page-local and result-set-wide statistics

## Problem

The Alert Rules page header shows three counters with mixed scopes:

- **Total Rules** comes from the paged backend response and describes the entire filtered result set.
- **Enabled on page** and **Triggered in 24h on page** are computed in the browser from only the rows loaded for the current page.

The page supports search and enabled filters and paginates server-side, so whenever a filter matches more rows than the current page size, two of the three counters describe a different scope than the first one. The labels even say "on page", which makes the header internally inconsistent and easy to misread during an alert-coverage review.

## Current behavior and reproduction

1. Open **Ops > Alert Rules** on an installation with more alert rules than one page (default page size 20).
2. Note the header shows three counters: Total Rules, Enabled on page, Triggered in 24h on page.
3. Observe that Total Rules matches the pagination total, while the other two only count the current page's rows.

`web/src/pages/ops/alerts.tsx` (around lines 381-389):

```ts
const enabledCount = rules.filter((r) => r.enabled).length;
const dayAgo = Date.now() - 24 * 60 * 60 * 1000;
const triggered24h = rules.filter(
(r) => r.lastTriggered && new Date(r.lastTriggered).getTime() > dayAgo,
).length;
```

Here `rules` contains only the current page, while `totalRules` is the backend `total` for the same filter. For example, with 60 matching rules, 40 enabled, and page size 20, the header can show "Total Rules 60 / Enabled 12 / Triggered in 24h 5" even though 40 rules are enabled overall.

The backend currently has no aggregate endpoint for rules; only `GET /api/alert-rules/page` (and the business variant) exists.

## Proposed behavior

- Add a summary endpoint for both cluster and business rule routes that returns `total`, `enabled`, and `triggeredSince` in a single query.
- Apply the same `search` and `enabled` filters as the paged rule feed so all header counters describe the same result set.
- Load the summary together with the page in the dashboard and render its values in the header.
- Update the labels so they no longer say "on page".
- Keep a safe fallback to the current page-derived values only if the summary request fails.

## Acceptance criteria

- [ ] `GET /api/alert-rules/summary` and `GET /api/business-alert-rules/summary` return `{total, enabled, triggeredSince}`.
- [ ] The summary applies the same `search` and `enabled` filters as the paged feed.
- [ ] All three header counters describe the same result set.
- [ ] Header labels no longer say "on page".
- [ ] The dashboard falls back to page-local values only when the summary request fails.
- [ ] Backend tests cover filter propagation and the business-domain legacy fallback for rules stored before the `domain` column existed.
- [ ] Frontend tests cover summary usage and fallback.

## Importance

Should-have. Operators use these counters to judge alert coverage and recent activity; the current mixed-scope header can mislead during a coverage review, but no data is lost.

## Duplicate check

Searched open and closed issues/PRs for `alert rule summary`, `alert rule counters`, `result-set-wide counters`, `enabled on page`. No existing issue or PR addresses the mixed-scope header counters on the Alert Rules page.

Start in web/src/pages/ops/alerts.tsx around the existing page-local counter calculations, then trace the cluster and business alert-rule routes behind the paged endpoints. Add summary responses with matching filters, connect them to the dashboard, and run backend and frontend tests covering filter propagation, the legacy business fallback, summary usage, and request-failure fallback.

Written by the indexing model from the issue text.