Aggregated API accepts tenant names with dashes that the tenant Helm chart will later reject #2375

Summary

ValidateApplicationName in pkg/apis/apps/validation/validation.go uses k8svalidation.IsDNS1035Label, which permits hyphens in the middle of the name (for example foo-bar). The tenant.name helper in packages/apps/tenant/templates/_helpers.tpl does the opposite: it explicitly fails any Release.Name whose splitList "-" .Release.Name does not have exactly two parts. A tenant name that contains a hyphen therefore passes aggregated API validation, creates a HelmRelease successfully, and then fails at Helm template time with a confusing error.

Reproduction

kubectl apply -f - <<'EOF'
apiVersion: apps.cozystack.io/v1alpha1
kind: Tenant
metadata:
  name: foo-bar
  namespace: tenant-root
spec: {}
EOF
# Tenant accepted by cozystack-api (DNS-1035 allows dashes)

kubectl get helmrelease -n tenant-root tenant-foo-bar -o jsonpath='{.status.conditions}'
# False, with message:
#   "The release name should start with \"tenant-\" and should not contain any
#    other dashes: tenant-foo-bar"

The user sees a successful kubectl apply, then has to dig into Flux/HelmRelease status to find the real rejection reason. The tenant guide in cozystack/website (content/en/docs/v1/guides/tenants/_index.md, Tenant Naming Limitations) explicitly tells users that dashes are not allowed in tenant names, but the API layer does not enforce this and diverges from the documented contract.

Relevant code

• pkg/apis/apps/validation/validation.go::ValidateApplicationName — uses IsDNS1035Label, which permits foo-bar.
• pkg/registry/apps/application/rest.go:158 — the only validation path for app.Name on Create.
• packages/apps/tenant/templates/_helpers.tpl lines 3–5 — the tenant.name helper that rejects names with extra dashes at template time.

Expected behavior

ValidateApplicationName (or a new validateTenantName helper gated on kindName == "Tenant") should reject any tenant name containing a hyphen at Create time, with an error message that mirrors the existing docs: "tenant names must be alphanumeric; dashes are not allowed". The current silent-accept-then-reconcile-fail path produces a bad user experience and diverges the API contract from the platform's own documentation.

Suggested fix

Add a kind-specific validator on the aggregated API path: when r.kindName == "Tenant", additionally require the name to match ^[a-z0-9]([a-z0-9]*)$ (alphanumeric only, no hyphens). Apply it before the IsDNS1035Label check so the error is specific to tenants.