inbound-antispam-panel: filter lists, written as rspamd maps

Step 5/12 of docs/plans/inbound-antispam-panel.md.

Store: AddSpamListEntry, ListSpamListEntries, DeleteSpamListEntry.
internal/inbound/lists.go validates and normalises an entry - sender
address, sender domain, client address or network (canonical text, an
IPv4-mapped address as IPv4, /0 refused) - and writes the lists as six
map files under /data/antispam (ANTISPAM_DIR), each atomically, 0644 in
a 0755 directory: the filter is another user in another container. All
six are written on every change and on every start with the relay on,
empty ones included. An entry whose maps could not be written is taken
back out of the table. The writer refuses a stored value with
whitespace, a newline or # in it.

The plan's allow.map / deny.map became one file per list and entry
type: to rspamd an IP map and a sender map are different map types.

deploy/antispam/rspamd/multimap.conf holds the rules; the fragment
mounts it and ./data/antispam into the sidecar. Deny is a prefilter
reject, allow a symbol weighing -100. Tried in a throwaway rspamd 3.11
container on the test server:
  - with allow as a prefilter accept, an address on both lists was
    accepted and an IP on both was refused - the rule that ran first
    decided; with the weight, deny won in all five mixed cases;
  - IPv4, IPv6, address (any case), domain (not its subdomains) match;
  - a rewritten file is reread in about ten seconds, no restart;
  - files that appear after rspamd started are loaded the same way.

No page edits the lists yet (step 6).

Checked on the test server, uncommitted tree: go vet ./... ok,
go test ./... ok (22 packages), make e2e ok - with the relay on
/data/antispam is 755 and holds the six maps, 644, empty.

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

docs/guide.md

@@ -851,6 +851,19 @@ with the message, and the upstream receives them with the mail. Copy the
 `antispam/rspamd/` directory next to the fragment; without the file accepted
 mail is still recorded, with no verdict.
 
+The same directory holds
+[multimap.conf](../deploy/antispam/rspamd/multimap.conf), the rules for the
+**allow and deny lists** kept in the panel. SelfPost does not apply the lists
+itself: it writes them as six files under `data/antispam/` (`allow_ip.map`,
+`allow_from.map`, `allow_domain.map` and the three `deny_` ones), the fragment
+mounts that directory into the sidecar, and rspamd rereads a file within
+seconds of a change - no restart. An entry is a sender address, a sender
+domain (that domain, not its subdomains) or a client address or network. A
+denied sender is refused outright. An allowed one is given a weight that no
+spam score outweighs, so it is accepted - unless a deny entry matches the same
+message: **deny wins**, whichever entries they are. The files are readable by
+anyone on the host; they hold addresses, not secrets.
+
 The panel only reports this setting; it does not change it. Every inbound
 domain page has a **Spam filter** box — on or off, what happens to mail while
 the filter is down, and that the filter belongs to the server, not to the