fix(nzbget): wait for gluetun tunnel before starting (prevents queue cancellation)

On pod start the nzbget container raced gluetun: /etc/resolv.conf points at
10.128.0.1 (reachable only via the WireGuard tunnel), so for the ~20s gluetun
needs to establish the tunnel every DNS lookup from nzbget returned EAI_AGAIN.
Any in-queue download that had articles fetched during that window dropped
below the HealthCheck threshold (~97.9%) and was auto-cancelled — even items
that would otherwise complete (saw 97.6-97.8% health = "very nearly fine").

Override the nzbget container's entrypoint to poll DNS resolution and only
exec /init once it succeeds. That's the direct test of "tunnel is up + DNS
works", which is what nzbget needs.

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

helm-values/nzbget_values.yaml

@@ -5,6 +5,25 @@ image:
   tag: "latest"
   pullPolicy: Always
 
+# Wait for the gluetun sidecar's tunnel to come up before starting nzbget.
+# Without this, nzbget races gluetun on pod start: /etc/resolv.conf points at
+# 10.128.0.1 (reachable only via the tunnel), so during the ~20s gluetun takes
+# to establish WireGuard, every DNS lookup from nzbget fails with EAI_AGAIN.
+# Any items in the queue at that moment hit nzbget's per-file HealthCheck
+# threshold (~97.9%) and get auto-cancelled — even ones that would otherwise
+# complete fine. Polling DNS resolution is the direct test: if it resolves,
+# the tunnel is up and DNS works.
+command:
+  - sh
+  - -c
+  - |
+    until nslookup news.newshosting.com >/dev/null 2>&1; do
+      echo "waiting for gluetun tunnel + DNS..."
+      sleep 2
+    done
+    echo "tunnel up, starting nzbget"
+    exec /init
+
 env:
   - name: PUID
     value: "1000"