dnscheck: query recursive resolvers directly, not the system one

The PTR check reported a correctly published record as wrong. The lookups
went through the container's resolver (127.0.0.11) which forwards to the
host's systemd-resolved, and systemd-resolved synthesises the reverse
lookup of the machine's own addresses from the local hostname rather than
asking public DNS. On the production host that meant

    81.30.105.2 -> magenta-pink-heliotrope16786 (does not match)

while public DNS has had 81.30.105.2 -> selfpost.mixfed.ru all along.

These checks exist to report what a receiving mail server sees, so they
now dial recursive resolvers themselves, defaulting to 1.1.1.1, 8.8.8.8
and 9.9.9.9 and overridable with SELFPOST_DNS_RESOLVERS. The e2e stand
sets it to its CoreDNS, which the `dns:` directive alone no longer covers.

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

deploy/docker-compose.yml

@@ -41,6 +41,10 @@ services:
       SEND_LOG_RETENTION_DAYS: "${SEND_LOG_RETENTION_DAYS:-90}"
       # Sliding idle timeout for the panel login session, in days (spec 7.6.6).
       PANEL_SESSION_IDLE_DAYS: "${PANEL_SESSION_IDLE_DAYS:-7}"
+      # Resolvers the panel's PTR/SPF/DKIM/DMARC checks query directly, so they
+      # report what the internet sees rather than what this host's own stub
+      # resolver synthesises. Empty uses public defaults.
+      SELFPOST_DNS_RESOLVERS: "${SELFPOST_DNS_RESOLVERS:-}"
     volumes:
       # All persistent state lives under /data (spec 9): SQLite DB, DKIM keys,
       # sasldb2, sender map, setup token. Back this up (panel button or the