fix: add operator liveness/readiness probes and gate readiness on the webhook server

[xcompass]

Problem

The Helm chart renders the manager Deployment with no probes. The binary already serves /healthz and /readyz on :8081, and config/manager/manager.yaml (kustomize) has the kubebuilder probes, but the chart never carried them over (upstream's chart doesn't have them either). Consequences:

• a hung manager is never restarted;
• the pod is marked Ready as soon as the container starts.

Changes

Chart (templates/deployment.yaml, values.yaml)

• livenessProbe → GET /healthz, readinessProbe → GET /readyz, on a named health port.
• Timings from the kubebuilder scaffold (liveness 15s/20s, readiness 5s/10s); each probe configurable and switchable under probes.*.
• --health-probe-bind-address=:<probes.port> passed explicitly, so the flag and the probe port can't drift.

Manager (cmd/main.go)

• /readyz now also runs mgr.GetWebhookServer().StartedChecker(). The webhooks are registered unconditionally with failurePolicy: Fail, and readiness is what adds the pod to the webhook Service's endpoints. With only healthz.Ping, the pod could go Ready before the webhook server listened, rejecting every HermesInstance create/update in that window, including GitOps syncs during an operator rollout.

Verification

• go build ./..., go vet ./cmd/...
• helm lint
• helm template: defaults render both probes + health port + the explicit bind flag; probes.*.enabled=false omits them
• hack/check-chart-image-tags.sh passes
• Scratch program on this module's controller-runtime: StartedChecker returns webhook server has not been started yet before Start, nil ~100ms after
• CI green
• Merge → release-please opens release 0.2.1 → merge that to publish
• configuration: bump the operator appset to 0.2.1, confirm probes pass live

Worth upstreaming to stubbi/hermes-operator afterwards, since the upstream chart has the same gap.

https://claude.ai/code/session_019rd9pDQddWJ2HQMjNvT1CA