Store a webhook's retention as a plain day count, 0 meaning forever (closes #539)

retention_days loses its column default of 30, and Webhook.RetentionDays
its default tag, so a 0 is stored as 0. The 365000-day stand-in
RetentionForeverDays and the BeforeSave hook that wrote it are gone. The
reaper and the "forever" label read 0 as forever, and the forms accept 0
or 1 to MaxFiniteRetentionDays; a blank field still gives 30 on the new
webhook form and keeps the stored value on the edit form. A negative
value, which the forms refuse, is still read as forever so it cannot put
the reaper's cutoff in the future.

Model: opus-5-5

README.md

@@ -1496,47 +1496,35 @@ the rotation chosen below that (none, monthly, daily or hourly). Both are
 validated as on the add target form, and the webhook and its targets are created
 together or not at all.
 
-| Field            | Type    | Description                                                 |
-| ---------------- | ------- | ----------------------------------------------------------- |
-| `id`             | UUID    | Primary key                                                 |
-| `user_id`        | UUID    | Foreign key → User                                          |
-| `name`           | string  | Human-readable name                                         |
-| `description`    | string  | Optional description                                        |
-| `retention_days` | integer | Days to retain events (default: 30; 0 means retain forever) |
+| Field            | Type    | Description                                   |
+| ---------------- | ------- | --------------------------------------------- |
+| `id`             | UUID    | Primary key                                   |
+| `user_id`        | UUID    | Foreign key → User                            |
+| `name`           | string  | Human-readable name                           |
+| `description`    | string  | Optional description                          |
+| `retention_days` | integer | Days to retain events; 0 means retain forever |
 
 **Relations:** Belongs to User. Has many Entrypoints. Has many Targets.
 
 The `retention_days` field controls how long event data is kept in the webhook's
 dedicated database before automatic cleanup.
 
-Setting `retention_days` to `0` means "retain events forever". Because the
-column carries a default of 30, a literal zero cannot survive an insert, so a
-zero is rewritten on save to a sentinel of `365 * 1000` days
-(`database.RetentionForeverDays`). The retention reaper recognises that sentinel
-and skips the webhook entirely, and the web UI displays such a webhook's
-retention as "forever" rather than as a day count.
+The value is stored as entered. Setting `retention_days` to `0` means "retain
+events forever": the retention reaper skips the webhook entirely, and the web UI
+displays its retention as "forever" rather than as a day count.
 
-Submitted `retention_days` values therefore fall into three bands, not two:
-
-- `1` up to `database.MaxFiniteRetentionDays` (106751 days, about 292 years) is
-  accepted as a finite retention.
-- Above that ceiling but below the retain-forever sentinel of 365000
-  (`database.RetentionForeverDays`) is rejected with a 400. This is the band the
-  cap exists for.
-- `0`, and `365000` or above, are accepted and mean retain forever, collapsing
-  to the sentinel — `0` in `Webhook.BeforeSave`, the large values in
-  `parseRetentionDays`. The large values are not out of range: the edit form
-  pre-fills the sentinel for a retain-forever webhook, so submitting that form
-  back unchanged has to keep meaning "forever".
-
-A negative value is in none of the three: `parseRetentionDays` rejects it with a
-400 before `BeforeSave` ever sees it.
+The new webhook and edit forms accept `0`, or a whole number of days from `1` up
+to `database.MaxFiniteRetentionDays` (106751 days, about 292 years). Anything
+else, a negative value or one above that cap included, is rejected with a 400. A
+blank field gives the default of 30 days (`database.DefaultRetentionDays`) on
+the new webhook form, and leaves the stored value unchanged on the edit form.
 
 The cap is not arbitrary: the reaper computes its cutoff as a `time.Duration`,
 an int64 nanosecond count, and a longer period overflows it. An overflowed
 cutoff lands in the future, where it matches every row, so the sweep would
 delete every event the webhook has instead of none. The reaper also clamps the
-value it reads to the cap, so no stored value can trigger that either.
+value it reads to the cap, and reads a negative value as forever, so no stored
+value can trigger that either.
 
 #### Entrypoint