Notification delivery retry only targets the current page

## Problem

The Notification Deliveries page exposes a bulk retry action, but it only retries the failed rows loaded on the current page. When a filter matches failed deliveries across several pages, the operator has to page through the feed and retry each page separately.

After a webhook or SMTP outage this is the common case: hundreds of deliveries can be FAILED at once, and the page size is 20.

## Current behavior and reproduction

1. Trigger a notification outage that leaves, for example, 120 FAILED deliveries.
2. Open **Ops > Notification Deliveries** and filter to the failing channel/instance.
3. Click the bulk retry action: it retries only the FAILED rows on the current page (up to 20).
4. Page to the next page and repeat; six manual page visits are needed for 120 failures, and stopping halfway leaves failures unrecovered.

`web/src/pages/ops/notificationDeliveries.tsx` (around lines 92-100):

```ts
const retryVisibleFailures = async () => {
const ids = items.filter((item) => item.status === 'FAILED').map((item) => item.id);
...
const result = await retryAlertDeliveries(ids);
};
```

`items` contains only the current page. The backend bulk endpoint `POST /api/system-alerts/deliveries/retry` accepts an explicit ID list, but there is no way to ask it to retry the failed deliveries matching the current filters.

## Proposed behavior

- Add `POST /api/system-alerts/deliveries/retry-filtered` that retries FAILED deliveries matching the current channel and instance filters.
- Bound the action to at most 100 rows selected in deterministic delivery-ID order, so one click cannot enqueue an unbounded storm of notifications.
- Validate the limit server-side and reject out-of-range values.
- Reuse the existing per-delivery retry path so state reset, audit records, and per-ID failure reporting behave identically.
- Return succeeded and failed counts so the UI can report the outcome.
- Add a "retry matching failures" action to the delivery page while keeping the existing current-page retry unchanged.

## Acceptance criteria

- [ ] The endpoint accepts channel/instance filters plus a limit, and validates that limit is 1–100.
- [ ] Only FAILED deliveries matching the filters are selected, in delivery-ID order.
- [ ] The action reuses the existing per-delivery retry path (state reset, audit, per-ID failures).
- [ ] The response reports succeeded and failed counts.
- [ ] The page offers the new action with current filters while keeping current-page retry unchanged.
- [ ] Backend tests cover bounded ID query, limit validation, and empty-result short circuit; frontend tests cover UI invocation.

## Importance

Must-have for incident recovery ergonomics. Retrying the filtered result set is the operation operators actually need after an outage; paging manually is error-prone and easy to abandon halfway, leaving failed notifications unrecovered.

## Duplicate check

Searched open and closed issues/PRs for `retry filtered deliveries`, `bulk retry deliveries`, `retry failed deliveries`, `notification retry`. No existing issue or PR adds a filter-based bulk retry; the current bulk endpoint only accepts explicit ID lists.

Start with web/src/pages/ops/notificationDeliveries.tsx around lines 92-100 and trace the existing retryAlertDeliveries flow and POST /api/system-alerts/deliveries/retry endpoint. Add the filtered endpoint and page action according to the acceptance criteria, then run the backend tests for bounded selection, limit validation, and empty results plus the frontend invocation test.

Written by the indexing model from the issue text.