DNS Challenge: no support for mTLS client certificates (e.g. reg.ru now requires it)

Problem

Some DNS providers now require mutual TLS (mTLS / client certificate) authentication on their API in addition to username/token.

Concrete example: reg.ru recently started requiring a client certificate for its API. Requests without a client cert are rejected with:

{"error_code": "NO_CERTIFICATE", "error_text": "The certificate not found"}

This breaks Let's Encrypt DNS-01 challenges and certificate auto-renewal for users whose DNS is hosted on such providers.

Impact

• Certificate issuance/renewal via the DNS Challenge fails.
• Users cannot configure a client certificate (cert + key) anywhere in the NPM UI for DNS challenge credentials — only username/password-style fields are exposed.

Suggested solution

Allow DNS challenge configuration to include an optional client certificate (cert + key, or a combined PEM) that is passed to the ACME client (lego / certbot DNS plugin) when talking to the provider API.

Workaround (for reference)

For the certbot-based path, this can be worked around by patching the bundled certbot-dns-regru plugin to send a client cert, but it is lost on container recreation and is not exposed via the UI. See certbot-dns-regru PR: https://github.com/shadowpercifal/certbot-dns-regru/pull/1

Start with the DNS challenge configuration flow and the ACME client/provider integration described in the issue, including the UI fields for credentials. Verify the reg.ru mTLS requirement and determine how certificate and key data should be passed to the provider. Done means users can configure a client certificate and successfully issue or renew a certificate through the DNS challenge.