Add ISPDB configuration for Migadu

[bluefoxconsultant]

Adds an ISPDB entry for Migadu, a mail host that serves
custom domains for its customers.

Why this belongs in ISPDB even though Migadu does host an autoconfig file

Migadu serves a correct config-v1.1.xml at autoconfig.migadu.com, and its
documentation asks customers to point autoconfig.<their-domain> at it with a
CNAME. That CNAME does not work on its own: autoconfig.migadu.com presents a
certificate for CN=admin.migadu.com, so any client that validates TLS gets a name
mismatch and falls through.

Measured on 2026-09-20, on two domains hosted by the same provider:

domain	autoconfig.<domain>	result
a domain with a plain CNAME to autoconfig.migadu.com	direct to Migadu	subjectAltName does not match hostname
a domain whose CNAME is proxied by a CDN presenting its own certificate	via the CDN	200, correct config

So the configuration only reaches a client when the customer happens to terminate
TLS themselves. For every other Migadu-hosted domain, nothing is discoverable:
autoconfig.thunderbird.net/v1.1/migadu.com currently returns 404, and these
domains publish no .well-known file either. The MX record is the only thing that
names the provider, which is exactly the lookup this entry serves.

About the contents

The IMAP and SMTP settings are copied verbatim from the file Migadu serves itself,
with %EMAILADDRESS% in place of the substituted address. The only change is
displayName, which Migadu serves as the generic "Mail".

The MX hostnames (aspmx1.migadu.com, aspmx2.migadu.com) are listed as domains so
the MX-based lookup resolves, following the pattern used in aol.com.xml.

Validated locally with tools/validate.py and tools/convert.py, which generates
three endpoints (migadu.com, aspmx1.migadu.com, aspmx2.migadu.com).

I have no affiliation with Migadu beyond being a customer; happy to close this if you
would rather approach them about fixing the certificate on their side, which would be
the better long-term fix.

[babolivier]

Hi @bluefoxconsultant, thanks for your PR!

Could you please share with me which email client(s) you have observed this failure mode with? As per Thunderbird's implementation, and the client implementation guidelines in our documentation (https://github.com/thunderbird/autoconfig/wiki/The-autoconfig-file#discovery-through-self-hosted-autoconfig-files), even if requesting autoconfig.[custom domain] fails (e.g. due to invalid certificates), clients should be able to see that the custom domain's MX record points to aspmx1.migadu.com and query autoconfig.migadu.com.