Report a zero-length or missing database that starts empty (closes #290)

Audit of the configuration and state read from files. Three cases
carried on silently: a zero-length webhooker.db booted as a first
start without the "created a new, empty database" warning, and a
missing or zero-length per-webhook database was replaced by an empty
one with only an INFO line, losing that webhook's events and pending
deliveries unannounced. All three now log that warning with the
file's path; CreateDB, which makes a new webhook's file, does not.

The README now says how .env, the main, per-webhook and archive
databases treat an empty file, and that a damaged per-webhook database
fails that webhook alone.

Model: opus-5-5

README.md

@@ -79,7 +79,8 @@ directory, read once at startup before anything else looks at the
 environment.
 
 The file is optional and having none is the normal case for a
-deployment. A file that is there but cannot be parsed aborts startup
+deployment. An empty file is the same as none: it has nothing in it to
+apply. A file that is there but cannot be parsed aborts startup
 with a message naming it, because a single malformed line makes none
 of the file apply: every variable in it silently reverts to its
 default, which is exactly the failure [Invalid values abort
@@ -564,7 +565,8 @@ its Argon2id hash. There is no second account and no forgot-password
 flow, so the banner and the reset command below are the only two ways
 in.
 
-A start that finds no `webhooker.db` in `DATA_DIR` also logs
+A start that finds no `webhooker.db` in `DATA_DIR`, or a zero-length
+one (which SQLite opens as an empty database), also logs
 `created a new, empty database` at `WARN`, with the file's path,
 shortly before the banner. On a deployment that has run before, that
 line means `DATA_DIR` was empty, most often because its volume is not
@@ -1939,10 +1941,17 @@ encryption key is generated and stored, and an `admin` user is created.
   the deliveries per target, kept through retention
 
 Per-webhook databases are created automatically when a webhook is
-created (and lazily on first access for webhooks that predate this
-feature). They are managed by the `WebhookDBManager` component, which
+created. They are managed by the `WebhookDBManager` component, which
 handles connection pooling, lazy opening, migrations, and cleanup.
 
+A per-webhook database that is missing or zero-length later means its
+webhook's events and pending deliveries are gone. The next time it is
+opened, an empty one is created in its place, so the webhook keeps
+receiving, and `created a new, empty database` is logged at `WARN` with
+the file's path. A file there that SQLite cannot open fails that
+webhook alone, with an `ERROR` naming the webhook on every access and a
+500 to its senders, so one damaged file does not stop the others.
+
 This separation provides:
 
 - **Isolation** — a high-volume webhook won't cause lock contention or
@@ -2007,7 +2016,9 @@ After each write the archive handle is closed
 and reopened, debounced to at most once per second, so an operator can
 move the archive file away for offline archiving without stopping the
 service; a moved or removed archive file is recreated automatically on
-the next write. An optional `expiry` in the target's config JSON (e.g.
+the next write. A zero-length archive file is written to as a new
+archive: SQLite opens it as an empty database, so it holds nothing to
+lose. An optional `expiry` in the target's config JSON (e.g.
 `{"expiry":"720h"}`) is validated when the target is created — the
 default (unset or the literal `never`) keeps rows forever — and rows
 older than the expiry are pruned each time the archive is (re)opened. An