fix(emailauth): IDNA-encode domains before DMARC DNS lookups

[AmirF194]

Summary

normDomain lowercased and trimmed a domain but never converted it to
its ASCII/punycode form. The DMARC tree walk builds every
_dmarc.<domain> TXT lookup from that value (discoverDMARCRecordWithEvaluator,
walkDMARCTree), so a message with an internationalized From domain
queried the raw Unicode label instead of the label the DNS zone
actually publishes records under, and evaluation silently degraded to
policy=none. internal/identity.normalizeDomain already does
lowercase + idna.Lookup.ToASCII for stored domains; this applies the
same pattern to the inbound auth path, with the same fallback to the
unmodified string on an encoding error.

Operational risk

None outside the emailauth package. normDomain also feeds the
displayed SPF/DKIM domain fields; those are already-ASCII values in
practice (SMTP HELO and DKIM d= tags), and the full existing suite
for this package (including those cases) is unchanged by this diff.

Test plan

• TestEvaluateDMARCEncodesUnicodeFromDomainForLookup (new):
  fails on main (queries _dmarc.münchen.example, the record
  under the punycode name is never found), passes on this branch.
• go test ./internal/emailauth/...: full package suite green.
• go build ./... and go test ./...: unaffected elsewhere.
• Not checked: real DNS resolution against a live internationalized
  domain (fakeTXTResolver only); the query-name construction is what
  this fix changes and what the test asserts.

Fixes #608

[jiashuoz]

Thanks for your contribution!!

[AmirF194]

Thanks for the quick review and merge. Glad the IDNA fix lines up cleanly with the pattern already in identity/store.go.