feat(chart): add startupProbe support to the pms container

[alphayax]

Why

The chart supports livenessProbe and readinessProbe (added in #117) but not startupProbe. That gap forces a bad trade-off, and the reason is already written down in #117's own review discussion:

if it's a particularly long db migration, the restart will just result in it being run again from the beginning and will indefinitely until the migration is allowed enough time to complete.

That is exactly right, and it is the problem. PMS answers 503 on /identity in two completely different situations:

1. while it runs database migrations at startup — transient, can take many minutes on a large library, and restarting makes it worse because the migration restarts from the beginning;
2. when the server is wedged — for example the Butler database-backup deadlock reported on the forums, where PMS keeps its process alive and answers 503 to everything indefinitely.

A liveness probe is the only thing that catches (2), because the process never exits. But with only a liveness probe available, its budget has to be stretched to cover the worst case of (1) — otherwise it turns a slow migration into a restart loop. So users end up either with no probe at all, or with a probe deliberately detuned to the point of being slow to help.

startupProbe is the Kubernetes primitive that separates the two: it suspends the liveness probe until the container answers once, then hands over. With it, the same deployment can tolerate a long migration and keep a tight liveness probe afterwards.

I hit this in production: PMS deadlocked on its nightly database backup and served 503 to every request for over 13 hours while the container stayed Running. Adding a liveness probe fixes the outage, but without a startupProbe I had to widen it to ~32 minutes to stay safe across version upgrades, which gives up most of the benefit.

What this changes

Four files, and no behaviour change for anyone who does not set the new value:

• templates/statefulset.yaml — one {{- with }} block, mirroring the existing two exactly, placed before livenessProbe.
• values.yaml — startupProbe: {} with a commented-out working example, in the same style as the neighbouring two.
• README.md — helm-docs row, alphabetical position.
• Chart.yaml — 1.7.1 → 1.8.0, matching how feat: add support for Service.spec.trafficDistribution #168, feat: add HTTPRoute label support #170 and feat(helm): add podSecurityContext #175 each bumped the minor version for an additive feature.

Verification

• helm template with no values: output is byte-identical to the unpatched chart apart from the helm.sh/chart version label. No probe key is injected by default.
• helm template with pms.startupProbe and pms.livenessProbe both set: both render, correctly nested under the container, readinessProbe correctly absent.
• The rendered manifest passes kubectl apply --dry-run=server against a live cluster.

Note on the example values

The commented example uses periodSeconds: 10 / failureThreshold: 180, i.e. a 30-minute startup budget. That is deliberately generous: the cost of an over-long startup probe is a slow first start, while the cost of one that is too short is a migration restarted from scratch, repeatedly. Happy to change the numbers if you would rather the example be less conservative.

[cilindrox]

LGTM - thanks @alphayax - just some comments on the wording.