Notification deliveries cannot be filtered by time range or alert text

## Problem

The Notification Deliveries page can filter by channel, status, and instance, but not by incident time or alert text. When investigating a notification failure, operators currently have to page through the feed and inspect rows one by one to find deliveries from a specific incident window or with a known error string.

## Current behavior and reproduction

1. Open **Ops > Notification Deliveries** after a notification incident.
2. Try to find all deliveries between 14:00 and 15:00 yesterday, or every row whose error mentions "webhook".
3. The page offers only channel, status, and instance selectors; there is no time-range picker and no search box, so the only option is paging through the full feed and reading rows manually.

`GET /api/system-alerts/deliveries/page` accepts only `channel`, `status`, `instanceId`, `page`, and `pageSize`. The repository query (`RmqAlertNotificationOutboxMapper.findPage` / `countPage`) joins `rmq_alert_notification_outbox` with `rmq_system_alert`, so the alert title and the delivery `last_error` are already available to the query, but neither can be filtered on.

## Proposed behavior

- Extend `GET /api/system-alerts/deliveries/page` with:
- `search` — case-insensitive free text matched against the alert title and the delivery `last_error`;
- `from` / `to` — delivery creation time bounds.
- Apply the new filters to both the page query and the total count so pagination stays consistent.
- Reject an inverted time range before querying.
- Normalize and trim the search term like the existing channel/instance filters.
- Add a search input and a time-range picker to the delivery page.
- Reset to the first page whenever a filter changes.
- Keep the existing channel, status, instance, and pagination behavior unchanged.

## Acceptance criteria

- [ ] `search` matches alert title and delivery `last_error` case-insensitively.
- [ ] `from`/`to` bound the delivery creation time; inverted ranges are rejected with 400.
- [ ] Page items and total count always reflect the same filters.
- [ ] Search terms are trimmed before querying.
- [ ] The page exposes a search input and time-range picker and resets to page 1 on any filter change.
- [ ] Backend tests cover search matching, time bounds, inverted ranges, and total-count consistency.
- [ ] Frontend tests cover filter forwarding and page reset.

## Importance

Should-have. Notification failures are normally investigated within an incident time window ("what failed between 14:00 and 15:00", "everything with 'webhook' in the error"). The current workaround — manual paging and eyeballing — is slow and error-prone during an incident.

## Duplicate check

Searched open and closed issues/PRs for `delivery filter`, `notification delivery search`, `delivery time range`, `delivery text filter`. No existing issue or PR adds time-range or text filtering to the delivery feed.

Start at GET /api/system-alerts/deliveries/page and trace RmqAlertNotificationOutboxMapper.findPage and countPage, then locate the Notification Deliveries page and its existing filter handling. Verify the current backend and frontend tests before making changes. Done means search and time filters are forwarded, validated, applied consistently to items and counts, and the page resets on filter changes with the listed tests passing.

Written by the indexing model from the issue text.