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

Each webhook's event database keeps running totals: one row for its
events, and one row per target for that target's deliveries, delivered
and failed, each with what retention removed. Every write to them
shares the transaction of the rows it counts. Deliveries get a
finished_at column; it and target_id end the status index, so each
target's deliveries finished in a window come from one index-range
query grouped by target. Retention deletes 1000 expired events per
transaction. The pane is its own template, its figures in tables.

The schema changes in place with nothing back-filled, so an existing
database must be recreated.

Model: opus-5-5

README.md

@@ -1065,7 +1065,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
@@ -1381,7 +1381,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).
 
@@ -1410,6 +1410,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)                      │
+│  └──────────────┘                                           │
 └─────────────────────────────────────────────────────────────┘
 ```
 
@@ -1662,6 +1669,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.
@@ -1729,33 +1737,65 @@ 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 |
+
+`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-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 and find the newest |
+| `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 `<`. 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 `created_at` is compared
+with `<` and SQLite narrows by a `<` 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
+only counts, keyed by a numeric `id` and by `target_id`:
 
 | Field        | Type      | Description |
 | ------------ | --------- | ----------- |
@@ -1797,6 +1837,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
@@ -2777,6 +2819,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)