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>

test/e2e/compose.override.yml

@@ -30,6 +30,10 @@ services:
       SELFPOST_HOSTNAME: mail.e2e.test
       # Plain HTTP panel for the test client — no reverse proxy in this stand.
       PANEL_COOKIE_SECURE: "false"
+      # The panel's deliverability checks query resolvers directly rather than
+      # the container's own (see internal/dnscheck), so the fake zone has to be
+      # named here too — `dns:` below only redirects the system resolver.
+      SELFPOST_DNS_RESOLVERS: 10.77.0.10:53
       # High enough that the whole suite's other ~10 sends (positive path,
       # level-2 test, the various rejected attempts) never trip it by
       # accident — only the dedicated level-1 test (negative check 4, which