fix(cozy-lib): converge the CA trust-anchor helper on the canonical name - #3408

Behind the facade of the incredibly lengthy comments I find it hard to see the PR itself. Leave the essence and help me understand why it's needed. A practical application of these templates somewhere in a chart will be helpful.

LGTM. This is the cleanest of the split-out PRs — a library template plus its tests, no production callers, and the security-critical piece (the two-guard PEM validation) I verified by running the regexes rather than by reading.

What it does

Three changes to cozy-lib.tls.caCertSecret, the render-time counterpart to the extraction controller:

1. Name convergence — <release>-ca-cert → <release>.tenant-ca, matching what the controller publishes. Safe: there are zero callers anywhere outside the helper's own tests.
2. Guard hardening — the certificate check moves from "contains a BEGIN CERTIFICATE line" to an anchored whole-value match requiring complete blocks and nothing else.
3. Adds internal.cozystack.io/tenant-ca: "true" so a helper-rendered anchor is selected by the same ApplicationDefinition include as a controller-projected one.

Verified

I extracted both regexes and ran them against nine inputs; the results match every test assertion:

The last row is the documented limit — a Helm template has no x509 parser, so a base64-alphabet body that happens to decode to key material passes the shape check. The guard comment states it, the test accepts armour around a base64-alphabet body it cannot decode (documented limit) pins it, and it points at the Go controller as the parsing backstop. Acceptable: this helper's input is chart-authored PEM at render time, not tenant-supplied, and the residual is a certificate-shaped blob no verifier will load rather than a key delivered under a key header.

Also checked and correct:

• The private-key guard runs first, so a cert+key bundle fails as must not contain private key material rather than as a shape error — the right message for the right mistake. Tested.
• merge (dict mandatory…) (.labels) gives the mandatory dict precedence, so a caller passing tenantresource: "false" cannot opt its object out of delivery. Sprig merge is dest-wins, and the test keeps the mandatory tenantresource label even when a caller tries to override it pins it.
• The printf "%v" coercion and the caCert: 0 → "required" wart are both documented and test-pinned.
• The earlier concern against this file — the "no second line of defence" comment that contradicted the guard below it — is gone.

Two nits, neither blocking

• The notExists: stringData["tls.crt"] assertion is close to vacuous: the helper structurally emits only ca.crt, so no input could produce tls.crt. The sibling tls.key assertion carries the real meaning (it is what a leaked key would land under); tls.crt is belt-and-braces on a strap that cannot come loose.
• The header comment says the object is "labelled so tenants reach it through … tenantsecrets". Precise, but worth one word: tenant-ca is the selector; tenantresource is the verdict the lineage webhook computes and the registry actually gates on. The comment two blocks down gets this right — only the summary compresses it.

Bottom line

No blocking findings. The rename is safe, the guard is provably correct within its stated limits, and the tests exercise real certificates rather than certificate-shaped strings, so they would catch a regression a fake fixture would sail past. Approving.

One thing I did not do: execute helm unittest on the suite — I verified the regex logic directly, which is the part that could be subtly wrong, and the assertions themselves are declarative.