Ask the Mercure hub for its health where it answers

Every E2E job has failed since 18 September with "dependency failed to start:
container pl_mail_test-mercure-1 is unhealthy". The hub was fine. Our
healthcheck was not.

dunglas/mercure is pinned to a floating tag, and the image moved its readiness
probe. "/healthz" now answers 404; `curl -f` treats a 404 as failure; the
container is marked unhealthy for ever while serving every subscription put to
it. Verified against the current image: /healthz gives 404, and
127.0.0.1:2019/mercure/health/ready gives 200 — which is the path the image's
OWN healthcheck has always used, and a container left to use it reports healthy.

Overriding the image's healthcheck with a URL of our choosing is precisely what
let the two drift apart, so the fix is to ask where it asks.

compose.yaml carried the same line, and that half was shipped. Nothing there
depends on the hub being healthy, so live updates kept working and the symptom
was an install permanently showing "(unhealthy)" in docker ps and in the
TrueNAS view — about nothing at all.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

compose.test.yaml

@@ -188,7 +188,13 @@ services:
       MERCURE_PUBLISHER_JWT_KEY: e2e-mercure-secret-not-for-production
       MERCURE_SUBSCRIBER_JWT_KEY: e2e-mercure-secret-not-for-production
     healthcheck:
-      test: ["CMD", "curl", "-f", "http://localhost/healthz"]
+      # The ADMIN endpoint, not "/healthz" on the hub port, and not a URL of
+      # our own choosing. The hub moved its readiness probe: "/healthz" now
+      # answers 404, `curl -f` treats that as failure, and the container is
+      # marked unhealthy for ever while serving perfectly. The image's own
+      # HEALTHCHECK has always used this path — overriding it with a guess is
+      # what let the two drift apart, and the guess is the half that rotted.
+      test: ["CMD", "curl", "-f", "http://127.0.0.1:2019/mercure/health/ready"]
       interval: 5s
       timeout: 5s
       retries: 10