Show a database target's archive file, size and last write in the target list (closes #397)

Each database target's row on the webhook page names its archive
file, as delivery.ArchivePath finds it, and shows its size on disk and
when it was last written, or "not created yet" when there is no file.
The figures come from the metadata of the file and its -wal only: the
size is the two together, and the last write the later of their
modification times, since a write lands in the -wal first.

Model: opus-5-5

README.md

@@ -1050,7 +1050,8 @@ Archive databases are the one exception the service is built for: the
 archive writer closes and reopens its handle around writes (debounced
 to at most one reopen per second), so an operator can move an
 `archive-….db` away for offline retention while the service runs,
-and it is recreated on the next write. See
+and it is recreated on the next write. The webhook page names each
+`database` target's archive file. See
 [Database Architecture](#database-architecture). That is a
 move-the-file-away workflow, not a substitute for the backup procedures
 above.
@@ -2033,6 +2034,14 @@ Because each `database` target has its own archive file, a target's
 webhook with different expiries keep two archives, each pruned on its
 own schedule.
 
+The webhook page shows, for each `database` target, its archive file's
+name, its size on disk and when it was last written. The size counts
+the `.db` and its `-wal` together, and the last write is the later of
+their two modification times, since a write lands in the `-wal` first.
+Both are read from the files' metadata; the archive is never opened.
+Before the first write, and after the file has been moved away, the page
+shows `not created yet` beside the name.
+
 Each `database` target on the webhook page has a **Download** button,
 which returns its archive as one gzipped JSON file,
 `archive-{webhook_name}-{target_name}-{YYYYMMDDTHHMMSSZ}.json.gz`, the