fix: label wildcard certs so apex SAN uses DNS-01

[acoshift]

Fixes #38. Alternative to #39 (do not merge #39 — it points at a ClusterIssuer that does not exist).

Companion: deploys-app/playbook#3 (apply that Issuer first).

Why

A wildcard Certificate is [apex, *.apex]. cert-manager auto-filters HTTP-01 only for the *. SAN. The shared Issuer/letsencrypt then HTTP-01s the apex, which loops forever behind Cloudflare/CDN (~17k failed /.well-known/acme-challenge/ requests/day on sim789.com).

PR #5 originally branched wildcard rows to ClusterIssuer letsencrypt-dns01, then simplified because that object “doesn't need to exist.” The mixed-Issuer filter claim is true for *. and false for the apex SAN.

A new ClusterIssuer is the wrong shape: certs live in deploys next to the namespaced Issuer, and ClusterIssuer secrets resolve from --cluster-resource-namespace (not deploys). Expanding the DNS-01 selector by dnsName cannot tell wildcard-apex from an apex-only cert (those have no _acme-challenge CNAME).

Change

Keep Issuer/letsencrypt. Label wildcard Certificates use-dns01=true. playbook#3 adds a DNS-01 solver with matchLabels for that label (cnameStrategy: Follow), so both SANs on that Certificate use DNS-01. Apex-only certs stay unlabeled and keep HTTP-01.

Created wildcard certs are not re-applied (only PendingCreate is). Those already issued via HTTP-01 on apex, so renewal stays as today until the row cycles back through PendingCreate.

Rollout

1. Apply playbook#3.
2. Land this PR.
3. Stuck in-flight wildcard Orders still have the old labels — delete the Certificate (or Order) after both land so cert-manager creates a new request with the label.