fix(certificate): refuse to share a certname, and require an explicit one

[slauger]

You were right on both counts: this should not be possible in the first place, and puppet was the wrong default. Two commits -- the guard, and the removal of the cause.

Why it was possible

A certname identifies exactly one entry on the CA, and a real Puppet CA refuses a CSR for a name it has already issued. The operator had no such guarantee: the webhook validated the certname format but not its uniqueness, there was no index on it, and the CRD defaulted it to puppet -- so two Certificates created without one collided by default rather than by mistake.

Two silent consequences

Adoption of a foreign certificate. Both submitCSR and fetchSignedCert address the CA by certname. With two Certificates racing, the second gets already has a requested certificate, which the code treats as success, and then fetches whatever holds that name. Nothing verified that the returned certificate belonged to the key we generated, so the TLS Secret would pair someone else's certificate with our private key. That fails at a TLS handshake much later, with an error pointing nowhere near here.

Revocation of someone else's certificate. handleCertificateCleanup revokes by certname, so deleting either Certificate revokes the entry the other one depends on.

To be clear about what was not wrong: there is no clean-before-sign anywhere, so the operator never took a certname away during signing.

The guard, in three layers

Webhooks are disabled by default, so admission alone would not hold.

1. Webhook rejects a duplicate at creation, naming the holder.
2. Controller refuses to sign and reports CertnameConflict with phase Error. Permanently: retrying cannot free a name. Modelled on the Pool hostname conflict in fix(controller): make status, metrics and hostname conflicts honest #564.
3. Key verification compares the returned certificate's public key against the private key it was requested for, so a foreign certificate is never written to a Secret.

A terminating Certificate releases its claim, and uniqueness is per CertificateAuthority rather than per namespace, because each CA keeps its own entries.

Removing the cause

certname is now required with MinLength=1 and has no default.

Beyond the collision, the default was wrong on its own terms: a certname is an identity, and puppet is only the right identity for the main server. PuppetDB and any further certificate need their own. The names agents connect through -- a load balancer, a service address -- belong in dnsAltNames, which the chart already derives from the Pool Services a server joins since #561.

Nothing in the repository relied on the default:

• certificates.yaml writes the value unconditionally; database.yaml already fails the render without one
• all sixteen CI value files set it explicitly, and so does the sample
• the same fail guard now covers server entries, the one path that could still fall through

Existing resources are unaffected: they carry certname: puppet materialised from the default, and the field is immutable anyway. New manifests that omit it are rejected, which is the point. Worth a line in the #540 release notes.

About the changed tests

TestSignCertificate_FullFlow now signs the submitted CSR instead of returning a canned certificate. It passed before because nothing verified the pairing. Two envtest cases that relied on the default were rewritten -- one of them now asserts the opposite, that an omitted certname is rejected.

Verification

make test (with envtest), make manifests, helm lint and golangci-lint 2.13.2 are clean. The chart guard was verified to fire on a values file without a certname. Documented under "Certname uniqueness" in the Certificate reference.

Closes the B1 blocker from the second review pass (2026-09-03), which had no issue of its own.