Terminally fail retrying deliveries with a non-retry target type (closes #82) (#104)

A delivery left in `retrying` whose target type was edited to a fire-and-forget
or unknown type was skipped forever by both restart recovery and the retry
sweep. Both paths now record a result row and mark it `failed`.

README.md

@@ -666,6 +666,18 @@ This means:
    durable fallback that ensures no retry is permanently lost, even under
    extreme backpressure.
 
+**Changing a target's type does not migrate in-flight deliveries.** Only
+`http` and `slack` targets own durable retries; `database` and `log`
+targets are fire-and-forget and never produce a `retrying` delivery. If a
+target's `type` is edited from a retrying type to a non-retrying (or
+unknown) one while one of its deliveries is still `retrying`, both
+recovery paths above terminally mark that delivery `failed` and record a
+`DeliveryResult` naming the current target type as the reason, logging it
+at warn level. The delivery is not re-dispatched under the new type — the
+operator never asked for that delivery — and the event itself remains
+stored in the per-webhook event database, so it can be redelivered
+manually.
+
 ### Circuit Breaker (HTTP Targets with Retries)
 
 HTTP targets with `max_retries` > 0 are protected by a **per-target circuit breaker** that