Index the event log's resubmit count with deleted_at (closes #325)

The event log's resubmit count, run on every page load over up to 25 event ids, read every live event in the webhook's database: GORM adds deleted_at IS NULL, and SQLite, keeping no statistics there, chose the deleted_at index over the resubmitted_from_id one. deleted_at is now the second column of idx_events_resubmitted_from_id, so the count is answered from that index for a whole page of events. A test checks SQLite's plan for the statement as GORM builds it, with a full page of ids. The README's event-tier indexes table lists the index. Pre-1.0: the index changes in the schema in place, with nothing for older databases.

Model: opus-5-5

README.md

@@ -1879,16 +1879,19 @@ tags, so `AutoMigrate` creates them on a fresh database:
 | `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 |
+| `events`           | `resubmitted_from_id`, `deleted_at` | The event log, which counts the events resubmitted from each event on a page |
 | `events`           | `created_at`                | Retention, which selects expired events by age |
 
 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.
+index but the last also covers `deleted_at`. It comes second in the `event_id`
+and `delivery_id` indexes, so that retention can use them without it. The event
+log's count, the one query on the `resubmitted_from_id` index, always carries
+`deleted_at IS NULL` and uses both columns. In the statistics' `events` index
+`deleted_at` comes first, because they compare `created_at` with a range (`>=`)
+and SQLite narrows by a range only on the last column it uses.
 
 #### Common Fields