check_mta_sts passes when the policy host does not resolve

## Problem

`check_mta_sts` (`domains/services.py:102-126`) confirms two things:

1. `_mta-sts.` has exactly one valid `v=STSv1;` TXT record.
2. `mta-sts.` is a CNAME to `mta-sts.`.

It never resolves that CNAME target, so the check passes even when the chain
does not terminate. The chain did not terminate in production:

```console
$ dig +short @ns1.relays.to mta-sts.mail.relay.relays.to CNAME # relay's nameserver
mta-sts.relays.to.
$ dig +short mta-sts.relays.to CNAME # registrar zone
mta-sts.mail.relay.relays.to.
```

The two zones pointed at each other, so no `mta-sts.` host
resolved at all. Domains still showed as verified, because the check stopped at
rule 2. #135 removed the loop, but the check stays blind to the next one.

## Impact

A DNS misconfiguration that breaks MTA-STS for every customer can pass domain
verification. The failure is silent: mail delivery degrades to opportunistic TLS
with no report, because a policy that does not resolve is treated as no policy.

## Suggested fix

Extend the check to confirm that the policy host terminates in an address
record. The check can resolve the CNAME target and require an `A`/`AAAA` answer,
or require that `mta-sts.` resolves end to end.

Points to decide:

- The check must stay cheap. It already makes two DNS queries, and a third
multiplies the cost across all domains on each verification pass.
- A resolver failure must stay a `False` result, not an exception.
- Domains that are currently marked verified can flip to failing on the next
check. Decide whether that is wanted, and whether the change needs a
re-verification run.

## Related

- #135 fixed the CNAME loop and serves the policy over HTTPS.
- The check asserts relay's own zone contents, so it cannot detect a fault in a
zone relay does not serve. State that limit in the docstring.