Report or refuse each unusable file webhooker reads (closes #290)

Audit of the files webhooker reads configuration or required state
from. A missing or zero-length database is reported with the "created
a new, empty database" warning and its path: webhooker.db at start,
and a per-webhook database at the latest at the next start, since
restart recovery now opens every webhook's database. The main
database's open errors name webhooker.db
(#459). webhooker resetpw
refuses a zero-length webhooker.db as it refuses a missing one. A
directory in place of a database file or its -wal or -shm is refused,
naming it; beside a -shm directory SQLite opened the database
read-only without a word. The README says how each case is treated.

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,11 +565,13 @@ 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
-mounted.
+line means `webhooker.db` was lost: either `DATA_DIR` was empty, most
+often because its volume is not mounted, or the file was zero-length,
+as a truncated copy leaves it.
 
 #### Recovering a lost admin password
 
@@ -612,7 +615,8 @@ What it will not do:
   the old password, so a reset underneath it would report a change the
   service does not honour.
 - **Create anything.** A `DATA_DIR` that does not exist, or that holds
-  no `webhooker.db`, is an error rather than a new empty deployment —
+  no `webhooker.db` or a zero-length one, is an error naming the path
+  rather than a new empty deployment —
   a mistyped path must not be built out and then reported as a success.
 - **Create an account.** A username that does not exist is an error.
   `resetpw` changes an existing account's password and nothing else.
@@ -993,6 +997,16 @@ its sidecars; a killed or crashed instance leaves them, and they must be
 carried with the `.db`. An archive the service has not opened since a
 crash keeps that crash's sidecars, even across a later clean stop.
 
+A missing sidecar is therefore normal, and SQLite makes new ones, so a
+`-wal` lost from a copy cannot be reported: the transactions it held
+are simply gone. SQLite reads a `-wal` up to its first damaged frame,
+as after a crash, and rebuilds a damaged `-shm`. A sidecar with the
+wrong mode is set back to `0600` when its database is opened. A
+directory in place of either is refused then, with an error naming it:
+for `webhooker.db` the server and `webhooker resetpw` stop, and an event
+or archive database fails as a damaged one does (see
+[Database Architecture](#database-architecture)).
+
 Configuration is **not** in `DATA_DIR` — it comes from the environment
 and from a `.env` file read out of the process working directory. Back
 that up with your deployment config, separately.
@@ -1075,13 +1089,17 @@ with any `-wal`/`-shm` beside it, or wait until there are none.
 1. Stop the service.
 
 2. Restore the **whole set together**: `webhooker.db` *and* every
-   `events-*.db` *and* every `archive-*.db`. A partial restore fails
-   quietly rather than loudly. Every database is opened `mode=rwc`, so a
-   missing `events-{uuid}.db` is **created empty** on first access
-   instead of erroring — the webhook comes back with its configuration
-   intact and its entire event history silently gone. Event databases
-   restored without `webhooker.db` are simply orphaned; nothing
-   references their UUIDs.
+   `events-*.db` *and* every `archive-*.db`. A partial restore is
+   reported, not refused. Every database is opened `mode=rwc`, so a
+   missing `events-{uuid}.db` is **created empty**: the webhook comes
+   back with its configuration intact and its entire event history
+   gone. The first start after the restore logs
+   `created a new, empty database` at `WARN` for each such file, with
+   its path, as it does for a missing `webhooker.db`. A missing
+   `archive-*.db` is recreated at its target's next delivery without a
+   warning, since moving one away is a supported workflow. Event
+   databases restored without `webhooker.db` are simply orphaned;
+   nothing references their UUIDs.
 
 3. Carry any `*.db-wal` and `*.db-shm` files that are in the backup.
    They are part of the database, and dropping a `-wal` silently
@@ -1939,10 +1957,19 @@ 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. Every webhook's database is opened when the service
+starts, so this appears at the latest at the first start after the
+file was lost. 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 +2034,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