Implementation proposal: validate retentionPeriod to prevent controller watch failure

[Azerothian]

Source: alexandrevilain#763 - "Retention period validation"

it's tempting for someone to use the "d" suffix in retention period, but that's not valid. It will prevent the operator from working as it cannot deserialize TemporalNamespace... Failed to watch *v1beta1.TemporalNamespace: time: unknown unit "d" in duration "30d" ... I tried to delete a temporal UI Deployment, and it was not recreated.

Why it fits: an invalid retentionPeriod on TemporalNamespace currently wedges the whole controller's watch on the type - one bad field takes down reconciliation for all namespaces. OpenAPI-level validation turns this into an immediate, user-visible API error instead of a controller outage.

Proposed implementation:

• Add kubebuilder validation on spec.retentionPeriod (and any other metav1.Duration fields): pattern ^(\d+h)?(\d+m)?(\d+s)?$ with MinLength=2, Type=string (pattern from the upstream reporter, already proven in their in-house controller).
• Audit other duration fields in TemporalCluster/TemporalNamespace APIs for the same exposure and apply the same pattern where Go time.ParseDuration is used.
• Add envtest tests asserting that 30d and 1w are rejected at admission while 30m, 24h are accepted.

Affected areas: api/v1beta1 type definitions, generated CRDs, CRD regeneration (make manifests).

Risks: a CRD update with a new pattern is additive for valid values; existing objects already stored with parseable durations are unaffected. No migration needed.