Evict archive writers on deletion and sweep idle archives (closes #89) (#95)

Per-webhook archive writers are now evicted when the webhook or its last
database target is deleted, and a background sweeper prunes expired rows from
idle archives that no longer receive writes. Archive files themselves are never
deleted.

README.md

@@ -531,6 +531,36 @@ older than the expiry are pruned each time the archive is (re)opened. An
 archive write failure is never silent success: the delivery records a
 failed attempt with the error and is marked failed.
 
+Because reopens only happen on writes, an archive belonging to a webhook
+that has stopped receiving events would never be pruned. A background
+**archive sweeper** closes that gap: on the same interval as the event
+retention reaper (`RETENTION_SWEEP_INTERVAL`) it prunes every archive
+whose database target declares a positive expiry, whether or not the
+webhook is still receiving traffic. The sweep never creates an archive —
+a webhook whose archive file does not yet exist is skipped, not
+initialised — it takes the same per-webhook lock the write path uses, so
+it can never interleave with a write, and it leaves the archive closed
+afterwards so the move-the-file-away workflow keeps working. Archives
+with no expiry, or the expiry `never`, are not touched by the sweep at
+all.
+
+Note that a webhook has one archive file but may carry more than one
+`database` target, each with its own `expiry`. The shortest expiry
+configured on any of them therefore governs the whole archive, and the
+sweep applies it whether or not the webhook is still receiving events.
+Configure a single `database` target per webhook unless you intend that.
+
+Deleting a webhook releases its archive: the delivery engine's cached
+archive writer is dropped and its file handle closed, so nothing lingers
+after the webhook is gone. The archive **file itself is deliberately
+left on disk**. Unlike the event database — per-webhook working storage
+that is hard-deleted with the webhook — an archive is long-term storage
+an operator may still want to keep or move away for offline retention,
+and destroying it as a side effect of deleting a webhook would be
+unrecoverable. Removing `archive-{webhookID}.db` is the operator's call.
+Deleting a webhook's last `database` target releases the writer the same
+way, and for the same reason leaves the file alone.
+
 The **Slack target type** sends webhook events as formatted messages to
 any Slack-compatible incoming webhook URL (works with Slack, Mattermost,
 and other compatible services). Each message includes event metadata