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

Each webhook's event database keeps one row of running totals: events,
deliveries and failures, and how many of each retention removed.
Storing an event, creating a delivery, a delivery becoming failed and
the retention sweep each update it in the transaction that writes or
deletes the rows it counts. Deliveries get a finished_at column, the
last column of the status index, so the last-10-minutes and
last-24-hours figures are index-range counts. The pane is its own
template, included at the top of the page.

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

Model: opus-5-5

README.md

@@ -1070,7 +1070,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`, `Totals`
 - each archive database on every open and reopen
 
 There is no schema version table, no migration ledger, and no down
@@ -1384,7 +1384,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 ten entities organized into two tiers: the
 **application tier** (user and webhook configuration) and the **event
 tier** (event ingestion, delivery, and logging).
 
@@ -1413,6 +1413,10 @@ tier** (event ingestion, delivery, and logging).
 │  ┌──────────┐       ┌──────────┐       ┌─────────────────┐  │
 │  │  Event   │──1:N──│ Delivery │──1:N──│ DeliveryResult  │  │
 │  └──────────┘       └──────────┘       └─────────────────┘  │
+│                                                             │
+│  ┌──────────┐                                               │
+│  │  Totals  │  (one row of running counts)                  │
+│  └──────────┘                                               │
 └─────────────────────────────────────────────────────────────┘
 ```
 
@@ -1665,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.
@@ -1732,6 +1737,29 @@ retries) is individually logged for full observability.
 
 **Relations:** Belongs to Delivery.
 
+#### Totals
+
+The one row of running counts in each event database, read by the
+statistics pane at the top of the webhook page.
+
+| Field                | Type    | Description |
+| -------------------- | ------- | ----------- |
+| `events`             | integer | Events ever stored, resubmitted copies included |
+| `deliveries`         | integer | Deliveries ever created, replays included |
+| `failures`           | integer | Deliveries that ever became `failed` |
+| `events_removed`     | integer | Events retention has deleted |
+| `deliveries_removed` | integer | Deliveries retention has deleted |
+| `failures_removed`   | integer | Failed deliveries retention has deleted |
+
+Each count changes in the transaction that writes or deletes the rows it
+counts. The pane shows each of the first three as a lifetime figure, and
+less what retention removed as the figure within retention, 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. 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
@@ -1739,10 +1767,10 @@ tags, so `AutoMigrate` creates them on a fresh and on an existing 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`       | `status`, `deleted_at`, `finished_at` | 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 deliveries by status and when they finished |
 | `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 |
 | `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`           | `deleted_at`, `created_at`  | Retention, which selects expired events by age, and the webhook page's statistics, which count recent events and find the newest |
 | `events`           | `created_at`                | Retention's delete of the expired events themselves |
 
 GORM's soft delete adds `deleted_at IS NULL` to these queries; retention's
@@ -1756,9 +1784,10 @@ 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` and `Totals` includes these fields from
+`BaseModel`. `Setting` is a bare key-value row with no `id`, no
+timestamps and no soft delete, and `Totals` is a single row of counts
+with only a numeric `id`:
 
 | Field        | Type      | Description |
 | ------------ | --------- | ----------- |
@@ -1800,6 +1829,7 @@ 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
+- **Totals** — running counts of the above, kept through retention
 
 Per-webhook databases are created automatically when a webhook is
 created (and lazily on first access for webhooks that predate this