fix(emailauth): close remaining RFC 9989 DMARC gaps

[jiashuoz]

Summary

Track the remaining RFC 9989 conformance gaps in inbound DMARC evaluation identified while reviewing #607.

The current implementation correctly requires at least one aligned, passing SPF or DKIM identifier before returning DMARC pass. These gaps are therefore expected to cause false negatives or inaccurate effective-policy metadata, not a known spoofed-mail authentication bypass.

Confirmed gaps

• Treat an otherwise valid DMARC record without p= as p=none instead of permerror.
• Support effective-policy behavior for np= and testing mode t=y, or avoid surfacing an effective policy value until it is calculated correctly.
• Convert a Unicode RFC 5322 From domain from U-label to A-label before DMARC lookup and alignment.
• For a null SMTP MAIL FROM, use the HELO identity for SPF evaluation as required by the SPF/DMARC model.

Acceptance criteria

• Missing-p and malformed/unsupported tag handling follows RFC 9989 sections 4.7, 4.8, and 4.10.1.
• The surfaced DMARC policy reflects applicable p, sp, np, and t semantics.
• U-label From domains are converted to A-labels before policy discovery and identifier alignment.
• Null reverse-path messages can use the HELO identity for SPF-based DMARC alignment.
• Unit tests cover each case and preserve the existing rule that DMARC passes only with an aligned SPF or DKIM pass.
• Developer-facing documentation describes the supported DMARC result semantics.

References

• RFC 9989 §3.2.4: https://www.rfc-editor.org/rfc/rfc9989.html#section-3.2.4
• RFC 9989 §4.7: https://www.rfc-editor.org/rfc/rfc9989.html#section-4.7
• RFC 9989 §4.8: https://www.rfc-editor.org/rfc/rfc9989.html#section-4.8
• RFC 9989 §4.10.1: https://www.rfc-editor.org/rfc/rfc9989.html#section-4.10.1
• RFC 9989 §5.3.1: https://www.rfc-editor.org/rfc/rfc9989.html#section-5.3.1
• Related PR: feat(api): publish canonical inbound authentication #607