Event log: show only the events with a failed or a pending delivery (closes #390)

The event log gains three links above the list: All, Failed (N) and
Pending (N), carried in a `show` query parameter; any other value shows
every event. Failed lists the events with a failed delivery, Pending
those with one pending or retrying, each once, under the full list's
50-row limit and order. A filtered list finds the matching deliveries
through `idx_deliveries_status`, looks up their events by ID and sorts
them, and reads the rows of only the events shown; its counts read the
deliveries alone. The line beside the heading says what a filter
counts, and Replay returns to the list it was pressed in. The README
and the comments naming the query parameters the service reads include
`show`.

Model: opus-5-5

README.md

@@ -1989,7 +1989,7 @@ tags, so `AutoMigrate` creates them on a fresh database:
 
 | Table              | Columns                     | Serves |
 | ------------------ | --------------------------- | ------ |
-| `deliveries`       | `status`, `deleted_at`, `finished_at`, `target_id` | Startup recovery, the retry and pending sweeps every 60 seconds and the queue-depth sampler every 30 seconds, which select deliveries by status, and the webhook page's statistics and target list and the webhook list, which count each target's deliveries by status and when they finished |
+| `deliveries`       | `status`, `deleted_at`, `finished_at`, `target_id` | Startup recovery, the retry and pending sweeps every 60 seconds and the queue-depth sampler every 30 seconds, which select deliveries by status, the webhook page's statistics and target list and the webhook list, which count each target's deliveries by status and when they finished, and the event log, which lists and counts the events with a failed delivery or one pending or retrying |
 | `deliveries`       | `event_id`, `deleted_at`    | The event log, which loads each event's deliveries, and retention, which counts and deletes the deliveries of expired events |
 | `delivery_results` | `delivery_id`, `deleted_at` | The event log, which loads the attempts of a page's deliveries, and retention, which deletes the attempts of expired events |
 | `events`           | `deleted_at`, `created_at`  | The webhook page's statistics, which count recent events |
@@ -2592,8 +2592,9 @@ The query string is never logged; it is replaced by the fixed marker
 limiter in front of them, so a query on a fixed 200 URL would otherwise
 buy the same amplification as an invented path. Nothing debuggable is
 lost: the only query parameters this service reads are the sign-in page's
-`next`, the page to return to, and `notice`, which names the line a page
-shows after an action.
+`next`, the page to return to, `notice`, which names the line a page
+shows after an action, and the event log's `show`, which picks the events
+it lists.
 
 Client-supplied request content does not leave the host by the other
 route either. The Sentry SDK attaches the request to every event it
@@ -3106,7 +3107,7 @@ returns to the page that was asked for.
 | `GET`  | `/hook/{id}/edit`        | Edit webhook form |
 | `POST` | `/hook/{id}/edit`        | Edit webhook submission |
 | `POST` | `/hook/{id}/delete`      | Delete webhook |
-| `GET`  | `/hook/{id}/events`      | Full Event Log |
+| `GET`  | `/hook/{id}/events`      | Full Event Log. `?show=failed` lists only the events with a failed delivery, and `?show=pending` only those with a delivery pending or retrying |
 | `GET`  | `/hook/{id}/events/{eventID}` | One event's own page: its details, the entrypoint it arrived at (for a resubmitted copy, the one the request it copies arrived at), its request headers, its whole body and every delivery of it |
 | `GET`  | `/hook/{id}/events/{eventID}/body` | Download an event's stored body. The pages show a body as text, cut at 32 KiB in the recent events and the event log, and leave a binary one out, so this is the only route that serves the stored bytes; it is offered wherever a body is cut or binary |
 | `POST` | `/hook/{id}/deliveries/{deliveryID}/replay` | Replay a finished delivery: creates a new delivery for the same event against the target's current configuration (30 per minute per bucket, then `429`) |