fix(deploy): detect the actually-live blue/green slot, stop nginx-sync clobbering the upstream

- ci-deploy.sh: read_active_port() now probes both slots on /api/health and
  picks the one that really answers; the upstream file only serves as a
  fallback when zero or both slots respond. A stray 'docker compose up' (or a
  clobbered snippet) can no longer derail the next deploy's cutover.
- nginx-sync.sh: cms_upstream_servers.conf is runtime-owned by ci-deploy.sh;
  only seed it when missing, never overwrite what a deploy wrote. This is the
  root cause of tonight's 502: a nginx-sync run reset the snippet (written to
  green:3003 by the last cutover) back to the dead slot A:3002.
- cms_upstream_servers.conf: restore the fresh-host seed default to slot A.

scripts/ci-deploy.sh

@@ -85,10 +85,24 @@ detect_blue_green() {
   return 0
 }
 
-# Op welke poort verwerkt nginx nu verkeer? Onbekend (of geen bestand) betekent
-# slot A, zodat de allereerste release op 3002 terechtkomt.
+# Welke poort is op dit moment ÉCHT live? Kijk niet naar het upstream-bestand
+# (dat kan door een losse `docker compose up` zijn ingehaald en naar een dood
+# slot wijzen), maar test welk slot werkelijk antwoordt op /api/health. Alleen
+# in een dubbelzinnige situatie (geen óf beide slots gezond) valt het script
+# terug op de huidige nginx-pointer; onbekend = slot A (eerste release op 3002).
 read_active_port() {
-  local port=""
+  local live="" port="" result=""
+  local count=0
+  for port in "$slot_a_port" "$slot_b_port"; do
+    if curl -sf --max-time 3 "http://127.0.0.1:$port/api/health" | grep -q '"database":true'; then
+      live="$live $port"
+    fi
+  done
+  for port in $live; do count=$((count + 1)); result="$port"; done
+  if [ "$count" -eq 1 ]; then
+    printf '%s' "$result"
+    return 0
+  fi
   port="$(grep -oE '127\.0\.0\.1:[0-9]+' "$upstream_file" 2>/dev/null | head -1 | cut -d: -f2 || true)"
   case "$port" in
     "$slot_b_port") printf '%s' "$slot_b_port" ;;