Switch Ghost healthcheck to nc (BusyBox wget lacks --max-redirect)

The previous fix used `wget --spider -S --max-redirect=0` to stop wget
from following Ghost's http→https redirect. That works on GNU wget but
fails on the BusyBox wget shipped in ghost:6-alpine — BusyBox wget
doesn't recognize --max-redirect, errors out on the unknown option,
and the healthcheck never passes. Container stayed in "health: starting"
forever.

`nc -z localhost 2368` is a plain TCP port check — universally
available via BusyBox, doesn't care about HTTP semantics, answers the
only question that matters: is Ghost listening? If the process is up
and the port is bound, nc exits 0 and Docker marks healthy. If Ghost
crashes or the port isn't bound, nc exits non-zero and Traefik pulls
the backend.

Side benefit: it's also much faster than an HTTP request.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: lunarthegrey

.github/scripts/patch.py

@@ -157,12 +157,11 @@ def patch_compose() -> None:
         "    env_file:\n"
         "      - .env\n"
         "    healthcheck:\n"
-        # Ghost redirects http→https when the Host header doesn't match its
-        # configured url, so a naive wget follows back out through Traefik
-        # and dies on setups without hairpin NAT. --max-redirect=0 stops
-        # the follow; we accept any HTTP response line as "Ghost is up".
-        '      test: ["CMD-SHELL", "wget --spider -S --max-redirect=0 -T 3 '
-        "http://localhost:2368/ghost/api/admin/site/ 2>&1 | grep -q 'HTTP/1'\"]\n"
+        # TCP port check. BusyBox (Alpine) wget doesn't support
+        # --max-redirect, so the HTTP-response approach fails; nc -z is
+        # universally available and answers the only question that matters
+        # for readiness: is Ghost listening on 2368?
+        '      test: ["CMD", "nc", "-z", "localhost", "2368"]\n'
         "      interval: 30s\n"
         "      timeout: 5s\n"
         "      retries: 5\n"