test: Prove wildcard certificates issue end to end

[scotwells]

Summary

Wildcard admission and the certificate service each have their own tests, but nothing yet drives a DNS-proven wildcard through the whole flow, from the certificate request to serving it on the edge.

This adds that coverage: one DNS-01 request naming only the wildcard, no HTTP challenge answer ever published for it, the issued certificate applied to the listener, and a certificate for the wrong name refused.

The certificate service no longer answers HTTP challenges for any hostname, so the separate guard this change used to add is gone and a test keeps the property instead.

This is stacked on #530 and changes no behaviour.

API

No API change. A wildcard hostname yields this certificate request in the project:

apiVersion: certificates.miloapis.com/v1alpha1
kind: TLSCertificate
spec:
  dnsNames:
    - "*.s3.example.com"
  issuance: DNS01
status:
  issuance: DNS01
  delegationTarget: k3f9q2x7.acme-dns.example.net
  conditions:
    - type: DNSDelegationReady
      status: "True"
    - type: Ready
      status: "True"

What the edge serves for the listener:

"*.s3.example.com":
  served: true
  covers:
    - bucket.s3.example.com
  doesNotCover:
    - a.bucket.s3.example.com
"*.example.com":
  served: false            # refused as material for another name
"bucket.s3.example.com":
  served: false

Test plan

• A DNS-proven wildcard requests one DNS-01 certificate naming only the wildcard, and cert-manager orders nothing for it
• An HTTP challenge listed for a wildcard gets no answer route
• Material for the wildcard is applied and admits the listener, and a broader or deeper certificate is refused
• Build, vet, lint and the full suite pass locally and in CI

Related to datum-cloud/enhancements#913