test(e2e): prove cert-manager gets a CryptOS certificate over ACME in a kind cluster #293

Summary

Nothing in CI shows that a real Kubernetes client can get a certificate from CryptOS over ACME. The ACME tests in internal/acme drive the handler with a Go client, and the lab run needs hardware. A kind cluster on a GitHub-hosted runner can close that gap: CryptOS runs from the repo's code on the runner, and cert-manager in the cluster enrols against it through an ingress, the way an operator would set it up.

Acceptance criteria

• An issuing node is stood up from the repo's code outside the OS image, reusing the in-process e2e harness (software key backend, embedded etcd, no TPM): a Root signs an Intermediate, and the Intermediate serves ACME from a pki.acme block parsed through config.Parse, built by the same code the boot uses.
• A kind cluster (pinned kind binary with checksum, kindest/node pinned by digest) runs cert-manager (pinned manifest with checksum), an ingress controller (pinned manifest with checksum) and a small test app pinned by digest.
• A ClusterIssuer points at the node with the CryptOS root as caBundle, an External Account Binding, and an http-01 solver through the ingress. The node validates the challenge through normal name resolution, with no validator bypass.
• A Certificate with an ECDSA P-384 private key goes Ready. The secret's chain verifies to the CryptOS root, the SANs match, and the serial is in the node's issued set.
• A forced renewal produces a new serial, also recorded by the node.
• task e2e:kind runs it locally on Linux and skips with a clear message when docker or kind is missing.
• A CI workflow runs it on pull requests that touch internal/acme, internal/config, internal/node, internal/e2e or the workflow, skips drafts, sets a timeout, and is not a required check.

Notes

Related: #110 (ACME for cert-manager and native clients).