fix(ci): health-probe the address the API actually binds, not loopback

The probe curled 127.0.0.1:25864 and got connection-refused against a daemon
that was running perfectly — the journal it captured on failure showed it
serving. The API binds the host's *mesh* address by design: the fleet has one
firewalld default zone, so a wildcard bind plus the named service would publish
it on every address the host carries, and the edge proxy is at another site, so
loopback-only would not serve the site at all.

`hostname -f` resolves to that mesh address, so the probe needs no value carried
between steps. Verified against the running service: loopback refuses, the FQDN
returns 200.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MSDYiibCtELsrjQq6KXnoi

.gitea/workflows/deploy.yaml

@@ -256,7 +256,15 @@ jobs:
         run: |
           set -euo pipefail
           for attempt in $(seq 1 30); do
-            if ssh "$API_HOST" "curl -sf http://127.0.0.1:$API_PORT/v1/healthz" > health.json; then
+            # NOT 127.0.0.1. The API binds the host's *mesh* address, never
+            # loopback and never 0.0.0.0 — the fleet has one firewalld default
+            # zone, so a wildcard bind plus the named service would publish it
+            # on every address the host carries, and the edge proxy is at
+            # another site so loopback-only would not serve it at all. Probing
+            # loopback therefore gets connection-refused against a perfectly
+            # healthy daemon. `hostname -f` resolves to the mesh address, so
+            # this needs no value carried between steps.
+            if ssh "$API_HOST" "curl -sf http://\$(hostname -f):$API_PORT/v1/healthz" > health.json; then
               cat health.json
               # `healthy` covers the database. Chain reachability is
               # deliberately not part of it: a chain configured before it