docs: document why CSRF is intentionally disabled in SecurityConfig

The previous comment implied CSRF was disabled as a temporary dev
convenience. Replaced it with an explanation of why it is safe with
the current Authorization-header-based auth scheme, and added a
clear note on when it must be re-enabled.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

backend/src/main/java/org/raddatz/familienarchiv/config/SecurityConfig.java

@@ -35,7 +35,12 @@ public class SecurityConfig {
     @Bean
     public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
         http
-                // CSRF für Entwicklung aus, damit wir Postman/REST Client nutzen können
+                // CSRF is intentionally disabled: every request from the SvelteKit frontend
+                // carries an explicit Authorization header (Basic Auth token injected by
+                // hooks.server.ts). Browsers block cross-origin requests from setting custom
+                // headers, so cross-site request forgery via a third-party page is not
+                // possible with this auth scheme. If the auth model ever changes to
+                // cookie-based sessions, CSRF protection must be re-enabled.
                 .csrf(csrf -> csrf.disable())
 
                 .authorizeHttpRequests(auth -> auth