Add a statistics pane to the webhook page (closes #368)

The webhook page opens with a statistics pane: entrypoints and targets, deliveries in progress, the last arrival, the retention period; events, deliveries and failures, lifetime and within retention; and events, failures and failure percentage over 10 minutes and 24 hours.

Running totals, one row per target plus one for events, sit in each webhook's event database and are written in the same transaction as the rows they count; retention prunes in paused, stoppable batches and subtracts what it removes. Window figures are index-range counts on a new finished_at column. An existing event database must be recreated.

Model: opus-5-5

README.md

@@ -1075,7 +1075,7 @@ unconditionally against whatever files it finds:
 - the main database on connect — `Setting`, `User`, `APIKey`, `Webhook`,
   `Entrypoint`, `Target`
 - each event database when it is lazily opened — `Event`, `Delivery`,
-  `DeliveryResult`
+  `DeliveryResult`, `EventTotals`, `TargetTotals`
 - each archive database on every open and reopen
 
 There is no schema version table, no migration ledger, and no down
@@ -1392,7 +1392,7 @@ The codebase uses consistent naming throughout (rename completed in
 
 ### Data Model
 
-webhooker's data model has nine entities organized into two tiers: the
+webhooker's data model has eleven entities organized into two tiers: the
 **application tier** (user and webhook configuration) and the **event
 tier** (event ingestion, delivery, and logging).
 
@@ -1421,6 +1421,13 @@ tier** (event ingestion, delivery, and logging).
 │  ┌──────────┐       ┌──────────┐       ┌─────────────────┐  │
 │  │  Event   │──1:N──│ Delivery │──1:N──│ DeliveryResult  │  │
 │  └──────────┘       └──────────┘       └─────────────────┘  │
+│                                                             │
+│  ┌──────────────┐  (one row: running counts of events)      │
+│  │ EventTotals  │                                           │
+│  └──────────────┘                                           │
+│  ┌──────────────┐  (one row per target: running counts      │
+│  │ TargetTotals │   of its deliveries)                      │
+│  └──────────────┘                                           │
 └─────────────────────────────────────────────────────────────┘
 ```
 
@@ -1674,6 +1681,7 @@ status across potentially multiple attempts.
 | `event_id` | UUID           | Foreign key → Event |
 | `target_id`| UUID           | Foreign key → Target |
 | `status`   | DeliveryStatus | One of: `pending`, `delivered`, `failed`, `retrying` |
+| `finished_at` | timestamp   | When the delivery became `delivered` or `failed` (nullable; empty while `pending` or `retrying`) |
 
 **Relations:** Belongs to Event. Belongs to Target. Has many
 DeliveryResults.
@@ -1741,33 +1749,70 @@ retries) is individually logged for full observability.
 
 **Relations:** Belongs to Delivery.
 
+#### EventTotals and TargetTotals
+
+Running counts in each event database, read by the statistics pane at the
+top of the webhook page. `EventTotals` is one row:
+
+| Field            | Type      | Description |
+| ---------------- | --------- | ----------- |
+| `events`         | integer   | Events ever stored, resubmitted copies included |
+| `events_removed` | integer   | Events retention has deleted |
+| `last_event_at`  | timestamp | When the newest event arrived (nullable; empty before the first); retention leaves it as it is |
+
+`TargetTotals` is one row per target, created by the first delivery to it:
+
+| Field                | Type    | Description |
+| -------------------- | ------- | ----------- |
+| `target_id`          | UUID    | The target (primary key) |
+| `deliveries`         | integer | Deliveries to it ever created, replays included |
+| `delivered`          | integer | Of those, how many became `delivered` |
+| `failed`             | integer | Of those, how many became `failed` |
+| `deliveries_removed` | integer | Its deliveries retention has deleted |
+| `failed_removed`     | integer | Its failed deliveries retention has deleted |
+
+Each count changes in the transaction that writes or deletes the rows it
+counts. The pane's lifetime events are `events`, and its lifetime
+deliveries and failures are `deliveries` and `failed` summed over the
+targets; each figure within retention is the same less what retention
+removed, so neither needs the rows themselves. Its last event is
+`last_event_at`, written in the transaction that stores the event, so it
+still shows once retention has removed every event. Its last-10-minutes and
+last-24-hours figures are counted from the `events` and `deliveries`
+indexes over just that window, the deliveries in one query grouped by
+target. Its failure percentage for a window is the deliveries that became
+`failed` in it out of all that became `delivered` or `failed` in it, and
+a dash when none did.
+
 #### Event-tier indexes
 
 These indexes on the per-webhook event databases are declared in the model
-tags, so `AutoMigrate` creates them on a fresh and on an existing database:
+tags, so `AutoMigrate` creates them on a fresh database:
 
 | Table              | Columns                     | Serves |
 | ------------------ | --------------------------- | ------ |
-| `deliveries`       | `status`, `deleted_at`      | Startup recovery, the retry and pending sweeps every 60 seconds and the queue-depth sampler every 30 seconds, which select deliveries by status |
-| `deliveries`       | `event_id`, `deleted_at`    | The event log, which loads each event's deliveries, and retention, which selects and deletes the deliveries of expired events |
+| `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, which count each target's deliveries by status and when they finished |
+| `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`  | Retention, which selects expired events by age |
-| `events`           | `created_at`                | Retention's delete of the expired events themselves |
+| `events`           | `deleted_at`, `created_at`  | The webhook page's statistics, which count recent events |
+| `events`           | `created_at`                | Retention, which selects expired events by age |
 
-GORM's soft delete adds `deleted_at IS NULL` to these queries; retention's
-deletes leave it out, but their lookups of expired rows keep it. SQLite keeps
-no statistics on these tables, and without them it rates the `deleted_at`
-index, which every live row matches, above an index on a column matched
-against several values or compared with `<`. So every index but the last also
-covers `deleted_at`. It comes second, so that retention's deletes can use the
-index without it, except in `events`, where `created_at` is compared with `<`
-and SQLite narrows by a `<` only on the last column it uses.
+GORM's soft delete adds `deleted_at IS NULL` to these queries; retention
+leaves it out. SQLite keeps no statistics on these tables, and without them it
+rates the `deleted_at` index, which every live row matches, above an index on
+a column matched against several values or compared with a range. So every
+index but the last also covers `deleted_at`. It comes second, so that
+retention can use the index without it, except in `events`, where the
+statistics compare `created_at` with a range (`>=`) and SQLite narrows by a
+range only on the last column it uses.
 
 #### Common Fields
 
-Every entity except `Setting` includes these fields from `BaseModel`.
-`Setting` is a bare key-value row with no `id`, no timestamps and no
-soft delete:
+Every entity except `Setting`, `EventTotals` and `TargetTotals` includes
+these fields from `BaseModel`. `Setting` is a bare key-value row with no
+`id`, no timestamps and no soft delete, and the two totals tables hold
+counts, plus `last_event_at` in `event_totals`, keyed by a numeric `id`
+and by `target_id`:
 
 | Field        | Type      | Description |
 | ------------ | --------- | ----------- |
@@ -1809,6 +1854,8 @@ encryption key is generated and stored, and an `admin` user is created.
 - **Events** — captured incoming webhook payloads
 - **Deliveries** — event-to-target pairings and their status
 - **DeliveryResults** — individual delivery attempt logs
+- **EventTotals** and **TargetTotals** — running counts of the above,
+  the deliveries per target, kept through retention
 
 Per-webhook databases are created automatically when a webhook is
 created (and lazily on first access for webhooks that predate this
@@ -2788,6 +2835,7 @@ webhooker/
 │   │   ├── model_event.go     # Event entity (per-webhook DB)
 │   │   ├── model_delivery.go  # Delivery entity (per-webhook DB)
 │   │   ├── model_delivery_result.go  # DeliveryResult entity (per-webhook DB)
+│   │   ├── model_totals.go    # EventTotals and TargetTotals (per-webhook DB)
 │   │   ├── model_apikey.go    # APIKey entity
 │   │   ├── password.go        # Argon2id hashing and verification
 │   │   ├── retention.go       # Retention reaper (per-webhook event expiry)
@@ -3052,7 +3100,8 @@ check, see [The login endpoint](#the-login-endpoint).
   before the app starts; the image's health check; and `docker exec`,
   unless given `--user`
 - GORM soft deletes on every entity that carries `BaseModel`, which is
-  all of them but `Setting` (data preserved for audit)
+  all of them but `Setting`, `EventTotals` and `TargetTotals` (data
+  preserved for audit)
 
 ### Shutdown