Add optional startupProbe to the runner Deployment

Why

A pod startup probe lets the chart gate "the pod is Ready" on more than just the existing exec-based readiness probe (pgrep). Concretely: when an operator runs boot-time work that has to complete before the pod accepts jobs — e.g. a deeper health check that dispatches a synthetic job through the standard Build pipeline — the current chart can't express that.

Without a startup probe, during a rolling update the new pod's readiness probe (pgrep) goes green almost immediately, the Deployment controller starts terminating old pods, and the canary may not yet have completed. Manager pods that fail their canary still take traffic before exiting.

What

Adds an optional startupProbe block to the runner Deployment template, rendered via toYaml when .Values.startupProbe is set, omitted otherwise. Defaults to empty so existing operators see no change to their rendered manifest.

When the operator sets the probe (e.g. against an HTTP endpoint the runner exposes for canary status), Kubernetes runs only the startup probe at boot. While it's running, the existing exec-based liveness and readiness probes are disabled and the pod stays NotReady. The Deployment controller treats the new pod as not-yet-Ready, so old pods are kept in service through the canary phase.

Liveness and readiness are deliberately left as-is in this MR: their exec handlers (/configmaps/check-live → gitlab-runner verify, pgrep gitlab.*runner) have meaningful semantics (token still valid, process alive) that operators rely on. Generalising those to full toYaml is a separate concern.

Companion runner MR

gitlab-org/gitlab-runner!6756 (merged) adds a /health/ready HTTP endpoint that gates on the boot-verify canary. Operator config in that MR's description.