fix: Login-userId war nicht stabil gegenüber Groß-/Kleinschreibung

/api/auth/login mintete die JWT-userId bisher aus dem roh eingegebenen Benutzernamen. LiteDBs
Standard-Collation vergleicht den eindeutigen Index auf Username aber case-insensitive - ein
Login mit nur einmal abweichender Schreibweise auf einem zweiten Gerät authentifiziert
erfolgreich, mintet aber eine andere userId. Da EventStore.GetCol(userId) diese direkt als
Dateiname für den Server-seitigen Event-Speicher nutzt, entstanden zwei komplett getrennte
Datenbestände für ein und dasselbe, aus Nutzersicht einzige Konto - Ursache dafür, dass ein
zweites Gerät trotz "since=0" durchgängig 0 Ereignisse erhielt.

UserStore.VerifyPassword(bool) durch Authenticate(UserEntry?) ersetzt, das bei Erfolg den
kanonisch gespeicherten Nutzereintrag liefert; /api/auth/login mintet Token und userId daraus
statt aus der Roheingabe.

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

LehrerApp.Api/Endpoints/Endpoints.cs

@@ -19,9 +19,15 @@ public static class Endpoints
         {
             if (string.IsNullOrWhiteSpace(req.Username) || string.IsNullOrWhiteSpace(req.Password))
                 return Results.Unauthorized();
-            if (!store.VerifyPassword(req.Username, req.Password))
-                return Results.Unauthorized();
-            return Results.Ok(new { token = Jwt(req.Username, secret), userId = req.Username });
+            var user = store.Authenticate(req.Username, req.Password);
+            // Der kanonisch gespeicherte Username aus UserStore.Authenticate (nicht req.Username!)
+            // wird als JWT-userId verwendet - LiteDBs case-insensitive Standard-Collation lässt
+            // einen Login mit abweichender Groß-/Kleinschreibung erfolgreich durch; würde man
+            // stattdessen req.Username übernehmen, würde jede andersartig getippte Anmeldung einen
+            // eigenen, komplett getrennten Server-seitigen Event-Speicher erzeugen (siehe
+            // UserStore.Authenticate).
+            if (user is null) return Results.Unauthorized();
+            return Results.Ok(new { token = Jwt(user.Username, secret), userId = user.Username });
         }).RequireRateLimiting("login");
     }
 

LehrerApp.Api/UserStore.cs

@@ -32,16 +32,28 @@ public class UserStore(string dataPath) : IDisposable
         return true;
     }
 
-    public bool VerifyPassword(string username, string password)
+    /// <summary>
+    /// Prüft die Anmeldedaten und liefert bei Erfolg den GESPEICHERTEN Nutzereintrag zurück -
+    /// nicht bloß true/false. Wichtig: LiteDBs Standard-Collation vergleicht Strings (und damit
+    /// auch den eindeutigen Index auf Username) standardmäßig case-insensitive, d.h. ein Login mit
+    /// abweichender Groß-/Kleinschreibung authentifiziert erfolgreich. Würde der Aufrufer daraufhin
+    /// den roh eingegebenen Benutzernamen als userId für den Server-seitigen Event-Speicher
+    /// verwenden (siehe EventStore.GetCol), würde ein einziger andersartig getippter Login auf
+    /// einem zweiten Gerät einen komplett getrennten, nicht überlappenden Datenbestand erzeugen,
+    /// obwohl es sich aus Nutzersicht um dasselbe Konto handelt. Der kanonisch gespeicherte Name
+    /// aus diesem Rückgabewert stellt sicher, dass die userId unabhängig von der beim Login
+    /// eingegebenen Schreibweise stets identisch ist.
+    /// </summary>
+    public UserEntry? Authenticate(string username, string password)
     {
         var user = Col.FindOne(x => x.Username == username);
-        return user is not null && PasswordHasher.Verify(password, user.PasswordHash);
+        return user is not null && PasswordHasher.Verify(password, user.PasswordHash) ? user : null;
     }
 
     public void Dispose() => _db.Dispose();
 }
 
-internal class UserEntry
+public class UserEntry
 {
     public ObjectId Id { get; set; } = ObjectId.NewObjectId();
     public string Username { get; set; } = "";