Switch tenant GHCR references and the Kyverno guardrail to per-tenant paths #3303

🤖 Generated by the Agentic Engineer

Evidence

Tenant pull authorization currently resolves the platform-wide path in three places:

• k8s/bases/apps/wedding-app/external-secret-ghcr-auth.yaml
• k8s/bases/apps/ascoachingogvaner/external-secret.yaml
• k8s/bases/infrastructure/resource-graph-definitions/tenant/resource-graph-definition.yaml (the RGD that materializes ghcr-auth for every future tenant)

k8s/bases/infrastructure/cluster-policies/best-practices/restrict-tenant-secret-stores.yaml currently permits tenants to read exactly infrastructure/ghcr/auth, so the guardrail encodes the over-broad path as the allowed one.

Impact

The reference switch and the policy must move together. Switching references while the policy still allows only the platform path fails tenant reconciliation; relaxing the policy first would widen what a tenant may read.

Expected behavior

Every tenant consumer resolves apps/<tenant>/ghcr/auth, the RGD templates that per-tenant path for new tenants, and the Kyverno policy allows a tenant to read only its own path — while platform-root Flux, Talos, and Kyverno consumers keep resolving the single authoritative path.

Acceptance criteria

• All three consumers switched, and the RGD parameterized so a new tenant inherits the scoped path by construction.
• restrict-tenant-secret-stores allows apps/<tenant>/ghcr/auth for that tenant and denies another tenant's path, with the deny proven by a policy test.
• Platform-root consumers demonstrably unchanged.

Blocked by provisioning: switching references before the sources exist is what closed PR #2722.