Helm chart still deploys images that are no longer published

The Helm chart references three images CI stopped building when Checkmate consolidated into the all-in-one image. It is pinned to the last tags that exist, so Helm users are stuck on v3.8.1 with no upgrade path.

## Current state

`charts/helm/checkmate/values.yaml` deploys:

| Line | Image | Status |
|---|---|---|
| `:2` | `ghcr.io/bluewave-labs/checkmate-client` | frozen at v3.8.1, not built |
| `:23` | `ghcr.io/bluewave-labs/checkmate-backend` | frozen at v3.8.1, not built |
| `:56` | `ghcr.io/bluewave-labs/checkmate-mongo` | frozen at v3.8.1, not built |

`.github/workflows/build-image.yml` publishes only `ghcr.io/bluewave-labs/checkmate` (line 43) and the transitional alias `ghcr.io/bluewave-labs/checkmate-backend-mono` (line 44). None of the three above.

The constraint is already documented in `Chart.yaml:6-10`:

> DO NOT bump appVersion past v3.8.1 until this chart is migrated to the all-in-one image (ghcr.io/bluewave-labs/checkmate). The checkmate-client / checkmate-backend / checkmate-mongo images this chart references are frozen at v3.8.1 — later versions are never published, so a bumped chart will fail to pull.

So the chart is knowingly stuck rather than broken by accident — but the effect on users is the same.

## Impact

Anyone installing via Helm gets v3.8.1 and cannot upgrade. This is the same class of problem as the deprecated `checkmate-backend-mono-multiarch` image that has been reported on Discord: an image name that no longer receives updates, with nothing in the install path signalling it.

## What migrating involves

More than swapping the image names in `values.yaml`. The chart currently models four workloads that the all-in-one image collapses into one:

- `templates/client/deployment.yaml` + `service.yaml` + `ingress.yaml` + `nginx-cm.yaml` — the frontend is now served by the API server, so the separate client deployment, its service, its nginx ConfigMap and its ingress all go away
- `templates/api/deployment.yaml` + `service.yaml` + `ingress.yaml` — becomes the single application deployment
- `templates/worker/deployment.yaml` + `scaledobject.yaml` — worth confirming whether the worker still runs as a separate deployment off the same image, or is embedded
- `templates/db/mongodb-statefulsets.yaml` + `mongodb-service.yaml` — `checkmate-mongo` was a custom image; this should move to upstream `mongo:8.0`, matching `docker/docker-compose.yaml`

Environment variables also changed. The chart still sets `UPTIME_APP_API_BASE_URL` and `UPTIME_APP_CLIENT_HOST` (`templates/client/deployment.yaml:31,33`), which the server no longer reads. Current variables are `DB_CONNECTION_STRING`, `JWT_SECRET`, `CLIENT_HOST`, plus the optional `CLIENT_CONFIG_*` overrides.

Two ingresses (`client` and `server`) likely collapse to one, which is a values-schema change for anyone already deploying the chart.

`charts/helm/checkmate/INSTALLATION.md:98` also documents `checkmate-backend` and needs the same treatment.

## Suggested outcome

A chart that deploys `ghcr.io/bluewave-labs/checkmate` plus upstream MongoDB, with `appVersion` free to track releases again, and an upgrade note for existing deployments whose `values.yaml` keys change.

Read charts/helm/checkmate/values.yaml and Chart.yaml alongside the listed client, API, worker, and MongoDB templates, then compare image publishing in .github/workflows/build-image.yml and MongoDB settings in docker/docker-compose.yaml. Confirm how the worker maps to the all-in-one image and how the two ingresses and values schema should change. Done means the chart deploys ghcr.io/bluewave-labs/checkmate with upstream mongo:8.0, tracks releases, and documents the upgrade and INSTALLATION.md changes.

Written by the indexing model from the issue text.