fix: Refresh-Token beim Login anfordern (Uta-Random-Logout, M1)

Ursache gefunden: Ohne Refresh-Token eskaliert das matrix-SDK jeden
Soft-Logout (z. B. abgelaufenes Access-Token, M_UNKNOWN_TOKEN mit
soft_logout=true) automatisch zu einem echten, destruktiven Logout —
_handleSoftLogout() versucht refreshAccessToken(), das ohne
gespeicherten Refresh-Token sofort mit "No refresh token available"
scheitert, und ruft danach client.logout() auf (client.dart:2374-2384
im matrix-Paket, Version 6.2.0).

Mit refreshToken: true beim Login bekommt der Client vom Server einen
Refresh-Token und kann einen Soft-Logout künftig durch stillen
Token-Refresh überstehen, statt die Sitzung zu zerstören. Falls der
Server keine Refresh-Tokens unterstützt, bleibt das Verhalten
unverändert (response.refreshToken ist dann null).

Wichtig: gilt nur für neue Logins. Bereits eingeloggte Geräte (z. B.
Uta) profitieren erst nach einmaligem Neu-Login. Zur Diagnose siehe
den mit 63e4919 eingeführten AuthLog.

UNGETESTET (Pi, kein GUI/Login hier möglich) – nächster PC-Lauf muss
den vollen Kreislauf prüfen: Login → Nachrichten → Logout → erneuter
Login → alte verschlüsselte Nachrichten noch lesbar?

lib/features/auth/login_notifier.dart

@@ -76,6 +76,12 @@ class LoginNotifier extends StateNotifier<LoginFormState> {
         identifier: mx.AuthenticationUserIdentifier(user: username),
         password: password,
         initialDeviceDisplayName: deviceName ?? 'Pyramid',
+        // Ohne Refresh-Token eskaliert das SDK jeden Soft-Logout (z. B. nach
+        // Ablauf des Access-Tokens) sofort zu einem echten, destruktiven
+        // Logout, weil `refreshAccessToken()` sonst mangels Refresh-Token
+        // fehlschlägt (siehe matrix-Paket Client._handleSoftLogout). Das ist
+        // der wahrscheinlichste Auslöser des Uta-Random-Logout-Bugs.
+        refreshToken: true,
       );
 
       if (Platform.isAndroid) unawaited(initFcm(client));