Non-ASCII zone and record names are passed through unchanged

The provider hands zone and Record.Name to the API verbatim. For an IDN zone that means Unicode is sent where the API, DNS itself and Let's Encrypt all want A-labels, and the failure that follows is hard to trace back to its cause.

Low priority for the Caddy path: CertMagic derives the zone from a DNS query (FindZoneByFQDN), so by the time AppendRecords is called it is already an A-label. It is direct libdns users who would hit this — someone who passes 你好.example.com. straight in.

Two ways out, and I do not have a strong opinion yet:

• Normalise at the boundary with golang.org/x/net/idna. This is what the sibling JavaScript implementation of the same API does (url.domainToASCII on both host and zone, once, before anything else). It costs a second dependency in a package that currently has exactly one.
• Reject non-ASCII input with a message naming the punycode form. No new dependency, and the caller learns what to do, but it is a refusal where the other implementation quietly copes.

Noting it now so it is not rediscovered later.

Start by tracing how direct libdns inputs reach AppendRecords, especially zone and Record.Name, and compare the existing sibling JavaScript behavior. Decide whether to normalize with golang.org/x/net/idna or reject non-ASCII values with a punycode-aware error; done means the chosen behavior covers both fields and makes IDN failures understandable.