feat(haproxy): X-Forwarded-Proto + X-Real-IP an alle Backends weiterleiten

User-Frage: „Werden via haproxy die echten IPs durchgereicht?". Antwort:
X-Forwarded-For ja (option forwardfor), aber Apps wie WordPress/Mailcow
brauchen zusätzlich X-Forwarded-Proto=https um Redirect-Loops zu
vermeiden, und X-Real-IP ist die bequeme single-value-Variante die viele
Tools out-of-the-box lesen (ohne die XFF-Chain parsen zu müssen).

Beide Frontends (public_https + mgmt_https) emittieren jetzt:
  http-request set-header X-Forwarded-Proto https
  http-request set-header X-Real-IP %[src]

Was Backends sehen:
  X-Forwarded-For:  <client-ip>             (defaults: option forwardfor)
  X-Forwarded-Proto: https                  (NEW)
  X-Real-IP:        <client-ip>             (NEW, single value)

PROXY-Protocol-Toggle pro Backend kommt nicht in diesem Release — der
Operator hat „nur Header-Variante" gewählt.

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

internal/haproxy/haproxy_test.go

@@ -43,6 +43,12 @@ func TestRender_BaselineHasFrontendsAndApiBackend(t *testing.T) {
 		"bind :443 ssl crt /etc/edgeguard/tls/",
 		"path_beg /.well-known/acme-challenge/",
 		"http-request redirect scheme https",
+		// Client-IP-Weiterleitung an Backends — XFF kommt aus
+		// defaults (option forwardfor), Proto + RealIP setzen wir
+		// pro public-Frontend explizit.
+		"option  forwardfor",
+		"http-request set-header X-Forwarded-Proto https",
+		"http-request set-header X-Real-IP %[src]",
 	} {
 		if !strings.Contains(out, w) {
 			t.Errorf("missing %q in baseline output:\n%s", w, out)