docs(auth): document XFF trust-the-proxy assumption on resolveClientIp

Pure-comment change: spell out that resolveClientIp's leftmost-X-Forwarded-For
strategy is safe only because Caddy strips client-supplied XFF before
forwarding. Future readers swapping the ingress have a tripwire. Addresses PR
#612 / Nora concern (XFF trust documentation).

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

backend/src/main/java/org/raddatz/familienarchiv/auth/AuthSessionController.java

@@ -78,6 +78,15 @@ public class AuthSessionController {
         return ResponseEntity.noContent().build();
     }
 
+    /**
+     * Resolves the client IP for audit-log purposes.
+     *
+     * <p>Trust model: the leftmost {@code X-Forwarded-For} value is taken at face value.
+     * This is correct <em>only</em> if the ingress (Caddy in production) strips any
+     * client-supplied XFF before forwarding — otherwise an attacker can pin audit-log
+     * IPs to whatever they want. Verify the reverse-proxy config before exposing this
+     * service behind a different ingress.
+     */
     private static String resolveClientIp(HttpServletRequest request) {
         String forwarded = request.getHeader("X-Forwarded-For");
         if (forwarded != null && !forwarded.isBlank()) {