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

Restart recovery and the 60s retry sweep both looked an orphaned
`retrying` delivery's target up in the registry and silently returned
when it did not implement `rescheduler`. If a target's type was edited
from a retry type (`http`/`slack`) to a fire-and-forget type
(`database`/`log`) or an unknown one while a delivery was still
retrying, that delivery stayed `retrying` forever.

Both sites now hand the delivery to one shared helper,
`failUnretryableRetry`, which records a `DeliveryResult` naming the
current target type as the reason and marks the delivery `failed`. It
logs at warn, not error: this is operator-caused state, not a system
fault.

Re-dispatching under the new type was rejected as it would perform a
delivery the operator never asked for; the event itself stays in the
per-webhook event database, so manual redelivery can recover it
deliberately.

Fire-and-forget targets never set status `retrying` under normal
operation, so this path stays unreachable for them in practice.

internal/delivery/export_test.go

@@ -188,6 +188,13 @@ func (e *Engine) ExportRecoverInFlight(
 	e.recoverInFlight(ctx)
 }
 
+// ExportSweepWebhookRetries exposes sweepWebhookRetries.
+func (e *Engine) ExportSweepWebhookRetries(
+	ctx context.Context, webhookID string,
+) {
+	e.sweepWebhookRetries(ctx, webhookID)
+}
+
 // ExportStart exposes start for testing.
 func (e *Engine) ExportStart(ctx context.Context) {
 	e.start(ctx)