Problem
#5085 fixed the `/ready` HTTP probe to retry instead of single-attempt-failing. Deploying that exact fix (live, edge-nl-01, 2026-07-11) immediately surfaced a second, previously-masked instance of the same bug right below it: the Docker container health-status check (`docker inspect ... .State.Health.Status`) is also a single, non-retrying check, and it caught the container in Docker's own transient `"starting"` state:
```
selfhost post-update check: probing http://127.0.0.1:8787/ready
selfhost post-update check: gittensory container status=starting
error: expected healthy or running, got starting
```
This was previously masked: before #5085, the `/ready` probe almost always failed FIRST (and immediately), so execution never reached this second check while the container was still genuinely "starting." Once `/ready` started retrying correctly, execution routinely reaches the status check while Docker's OWN healthcheck (which re-probes `/ready` on its own independent `interval`/`start_period` schedule) hasn't completed its first cycle yet.
Fix
Retry the status check the same way, but only for `"starting"` specifically — any other non-healthy/running status (`unhealthy`, `exited`, `restarting`, ...) is a real problem and should fail immediately rather than burning the full retry budget.
Problem
#5085 fixed the `/ready` HTTP probe to retry instead of single-attempt-failing. Deploying that exact fix (live, edge-nl-01, 2026-07-11) immediately surfaced a second, previously-masked instance of the same bug right below it: the Docker container health-status check (`docker inspect ... .State.Health.Status`) is also a single, non-retrying check, and it caught the container in Docker's own transient `"starting"` state:
```
selfhost post-update check: probing http://127.0.0.1:8787/ready
selfhost post-update check: gittensory container status=starting
error: expected healthy or running, got starting
```
This was previously masked: before #5085, the `/ready` probe almost always failed FIRST (and immediately), so execution never reached this second check while the container was still genuinely "starting." Once `/ready` started retrying correctly, execution routinely reaches the status check while Docker's OWN healthcheck (which re-probes `/ready` on its own independent `interval`/`start_period` schedule) hasn't completed its first cycle yet.
Fix
Retry the status check the same way, but only for `"starting"` specifically — any other non-healthy/running status (`unhealthy`, `exited`, `restarting`, ...) is a real problem and should fail immediately rather than burning the full retry budget.