Feature: ACME DNS-01 challenge delegation (CNAME alias) for least-privilege DNS tokens

Bắt đầu với entrypoint.sh và lớp trừu tượng dns_providers hiện có; theo dõi lời gọi ACME hiện tại, việc xử lý TXT và đường dẫn lỗi CAA. Xem lại luồng ACME_CHALLENGE_ALIAS được đề xuất cùng các manual auth/cleanup hooks của certbot. Hoàn tất khi việc ủy quyền TXT của alias-zone hoạt động mà không cần quyền truy cập vào production-zone, đồng thời CAA accounturi chính xác được in ra và xác minh, hoặc việc không tồn tại được báo cáo rõ ràng.

Problem

dstack-ingress issues certs via ACME DNS-01, which requires a DNS provider API token that can edit the served domain's own zone (to write the _acme-challenge TXT, and — per entrypoint.sh — to set the A record and CAA).

In our deployment the served name (e.g. svc.example.com) lives under a shared production zone (example.com) that holds many unrelated production records. Handing the enclave a token for that zone is too broad:

• Cloudflare API tokens scope only to zone level — there is no way to restrict a token to a single subdomain/record.
• Managing the subdomain as its own Cloudflare zone requires an Enterprise plan.

So today we'd have to give the enclave a token that can edit our entire example.com zone, which we can't accept.

Proposed feature: DNS-01 challenge delegation (CNAME alias)

Let the operator delegate only the _acme-challenge to a separate zone they fully control, so the enclave's token never touches the production zone:

1. Operator adds one static record in the production zone:
   _acme-challenge.svc.example.com CNAME <label>.<delegation-zone>
2. dstack-ingress writes the challenge TXT into <delegation-zone> (its token scoped only to that zone). Let's Encrypt follows the CNAME during validation.

This is a standard least-privilege ACME pattern (acme.sh --challenge-alias, lego, cert-manager, and Cloudflare's own "Delegated DCV" all support it), and it fits dstack's zero-trust ethos.

Design sketch (opt-in, non-breaking)

• New env ACME_CHALLENGE_ALIAS=<delegation-zone>; unset ⇒ current behavior, unchanged.
• When set, run certbot with --manual --preferred-challenges=dns + auth/cleanup hooks that reuse the existing dns_providers abstraction to write the TXT under the alias zone instead of _acme-challenge.<domain>.

Important: CAA handling (needs an explicit decision)

entrypoint.sh currently auto-sets the accounturi CAA
(letsencrypt.org;validationmethods=dns-01;accounturi=$ACCOUNT_URI) on the served domain, using the same token. In delegation mode the token cannot touch the served domain's zone, so this auto-set won't work — and the current code treats a CAA-set failure as not critical, which would silently drop the accounturi lock (the forge-prevention against a non-TEE account issuing a cert for the domain).

To avoid silently weakening security, in delegation mode the feature should:

• print the exact CAA record the operator must set statically in the served zone (including the account URI), and
• verify the CAA is present / warn loudly if absent, instead of silently continuing.

This keeps the "only the TEE's ACME account can issue" guarantee explicit, rather than silently lost.