entrypoint: /data/opendkim removed, as planned for the release after 2.8.0

2.8.x copied the keys from /data/opendkim to /data/dkim and kept the old
tree for a rollback to 2.7.x "until the next release"
(docs/plans/panel-dkim-signing.md, Q2); the owner's "потом режь 2.9.0"
(2026-10-16) makes this that release. The entrypoint now removes the tree
once /data/dkim holds a key, and says so. A /data with keys under the
old tree only - one that never ran 2.8.x - stops the start with a message
to run 2.8.x first, rather than let the panel give the server's own name
a new key its published record would not match; the tree is left as it
was. Gone with it: the copy into /data/dkim.new, the tree's
normalisation, its exemption from the general hand-over, its key link in
drop_links, and the backup's exclusion of "opendkim" (dead: the panel
never sees the tree now).

Tests: e2e TestStartsOnA28Data replaces TestStartsOnA27Data - a /data as
2.8.x left it (both trees, a queue of foreign uids, a rotation due): the
old tree is gone, the key under /data/dkim is the one left, the selector
table names it, the queue is Postfix's by name; TestRefusesA27Data - the
start stops, says why, leaves the old key and makes no new one. go vet +
go test (26 packages) and make e2e (all pass) on the test server for this
tree.

Docs: guide § Upgrading "To 2.9.0" (rollback to 2.8.x needs nothing, to
2.7.x only from a 2.7.x backup; the 2.7.x rollback paragraph says it is
for 2.8.x only and keeps naming 2.7.0), guide § backup, architecture
(the old tree, § Persistence's table and the restore line), security
§ Backup, development's e2e paragraph, the plan's key step; CHANGELOG
[Unreleased] § Removed.

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

docs/guide.md

@@ -684,7 +684,17 @@ was, for a rollback, until the next release, and which a full backup leaves
 out. The selector table, `data/dkim/selectors`, is written from the database
 at every start, before the signer serves.
 
-**Rolling back to 2.7.x** after that: the 2.7.x image signs with OpenDKIM
+**To 2.9.0** from 2.8.x there is nothing to do: the first start removes
+`data/opendkim`, the key tree 2.7.x read, which 2.8.x kept for a rollback,
+and says so (`entrypoint: removed /data/opendkim, the key tree of 2.7.x;
+the keys are under /data/dkim`); the keys under `data/dkim` stay as they
+are. From 2.7.x, start 2.8.x once first: an image of 2.9.0 on a `data`
+whose keys are under `data/opendkim` only stops at the start and says so,
+rather than give the server's own name a new key. Rolling back from 2.9.x
+to 2.8.x needs nothing; to 2.7.x, the old tree is gone - only a full backup
+of 2.7.x brings it back.
+
+**Rolling back to 2.7.x** from 2.8.x (only): the 2.7.x image signs with OpenDKIM
 from `data/opendkim`, which holds the keys as they were at the upgrade. A
 domain added under 2.8.x has no key there, and 2.7.x sends its mail
 unsigned; one deleted and added again under 2.8.x has its old key there,
@@ -771,9 +781,7 @@ as themselves, the host's IPv6 address and `127.0.0.1` as `172.18.0.1`.
 domains' DKIM keys under `data/dkim/`, all applications' SASL credentials,
 `manifest.json` with the version that created it), plus `docker-compose.yml`,
 `.env`, and `certs/` from the operator directory next to `./data`. Delivery
-logs under `data/log/` are excluded, so is `data/opendkim/` (the key tree an
-installation upgraded from 2.7.x keeps for a rollback, see
-[Upgrading](#upgrading)), and so is the Postfix queue: the archive is taken while the
+logs under `data/log/` are excluded, and so is the Postfix queue: the archive is taken while the
 instance runs, and a copy of a queue Postfix is working on can hold a message
 twice or not at all. Mail still waiting for delivery is therefore not carried
 over, and a restored instance starts with an empty queue; to keep the queue,