inbound-antispam-panel: the backup holds the lists; Inbound log accepted

Step 7/12 of docs/plans/inbound-antispam-panel.md. A full backup walks
all of /data, so data/antispam/ was in it from the day the directory
existed; TestCreateIncludesStateExcludesTransient now holds that. On
the first start after a restore the maps are written again from the
database (mailStack.Resync, already there). The guide says what is not
in a backup: the antispam/ directory with the compose fragment and the
rspamd configuration, which is installation and not state.

The plan records the owner's acceptance of Inbound > Log (2026-10-12,
"Этот экран утверждаем") and what he changed on the way to it.

go test ./internal/backup/ ok.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/guide.md

@@ -712,6 +712,15 @@ needed) for the new hostname or proxy, then `docker compose up -d`. The archive
 carries `certs/` from the old host — re-issue certificates when the hostname or
 IP changes. Set up the reverse-proxy vhost separately (not in the backup).
 
+The inbound log and the filter lists are in the database and so in the
+backup, and so are the list files under `data/antispam/`; the panel writes
+those files again from the database on the first start after a restore. What
+the backup does not hold is the spam filter's own side: the `antispam/`
+directory with the compose fragment and the rspamd configuration. Like the
+reverse-proxy fragments it is part of the installation, not of its state -
+copy it from [deploy/antispam/](../deploy/antispam/) again, or the restored
+instance runs with no filter.
+
 **Restoring an encrypted (`.spbk`) backup** needs a running container to
 decrypt it first — any container with the `selfpost-backup` CLI works; decryption
 does not read `/data` and performs no version check. Start one normally