Support Configurable Agent TLS Certificate Expiration

[Mmoushon201]

Is your feature request related to a problem? Please describe.

Currently, the Zarf Agent's TLS certificates are hardcoded with a validFor constant (approx. 375 days). For systems deployed in disconnected or Read-Only (RO) environments that may remain in the field for years without updates, this 1-year expiration creates a hard failure point.

Users need a way to configure the agent certificate lifetime (e.g., up to 10 years) during the initialization process to ensure long-term stability in air-gapped or immutable environments.

Describe the behavior you'd like

Given a user is deploying Zarf to a long-lived, disconnected environment.
When the user executes the zarf init command with a specified certificate duration flag (e.g., --agent-cert-duration=87600h)
Then the Zarf Agent TLS certificates and CA should be generated with the requested expiration, and the MutatingWebhookConfiguration and zarf-state secret should reflect this extended validity period.

Describe alternatives you've considered

• Generate certs externally — Create a CA + server cert/key with desired lifetime; server cert SAN must include agent-hook.zarf.svc
• Replace agent-hook-tls secret — Delete and recreate the TLS secret in the zarf namespace with the new cert and key
• Restart agent pods — kubectl -n zarf rollout restart deployment agent-hook so pods serve the new cert
• Verify agent health — Confirm the restarted pods are running and the liveness probe at /healthz:8443 passes
• Patch MutatingWebhookConfiguration zarf — Update caBundle on all 8 webhook entries to the base64-encoded new CA cert
• Update zarf-state secret — Extract the state JSON, replace agentTLS.ca, agentTLS.cert, and agentTLS.key with the new PEM values, write it back
• Avoid running zarf tools update-creds agent afterward — It will overwrite everything with a fresh 375-day cert generated from the hardcoded validFor constant