Bündel A-D: Race-Fixes, JWT-Cleanup, Storage-Watchdog, HTTPException, SW by-v1112

A — Founder-Number-Race (Audit-Fund aus Agent 2)
- partner.py PATCH /admin/users: SELECT COUNT + UPDATE+1 →
  atomares UPDATE mit Sub-Query. WHERE-Klausel prüft Limit + dass
  User noch nicht is_founder=1 ist. rowcount=0 → 'Plätze vergeben'.
- dogs.py POST /dogs (erster Hund triggert Gründer-Aktivierung): selbes
  Pattern. Zusätzlich AND is_founder_pending=1 als Schutz.
- Sub-Queries werden gegen Snapshot VOR dem UPDATE evaluiert
  (SQL-Spec), daher keine 'doppelte Nummer' möglich auch wenn zwei
  User gleichzeitig den ersten Hund anlegen.

B — JWT-Blacklist-Cleanup-Job
- _purge_expired_jwt() in auth.py existierte schon, war aber nicht
  verdrahtet → jwt_blacklist wuchs monoton.
- Neuer Scheduler-Job _job_purge_jwt_blacklist täglich 03:30
  (nach poison_archive, in ruhiger Zeit), mit _log_job für
  Error-Digest.

C — iOS Storage-Quota-Watchdog (PWA-Stabilität)
- offline-indicator.js: _checkStorageQuota() per
  navigator.storage.estimate() beim Init + alle 60s im Interval.
- Bei >=80% Auslastung: Tile-Cache auf 100 Einträge trimmen (statt
  default 500). Verhindert QuotaExceededError auf iOS-PWA (~50MB).
- Bei >=90%: einmaliger Toast-Hinweis pro Session
  'Speicher fast voll — Tiles werden gelöscht'.

D — HTTPException in osm.py
- 'raise Exception("Alle Overpass-Instanzen fehlgeschlagen")' wurde
  zu HTTP 500 → User-unfriendly. Jetzt 503 mit klarer Message
  'Kartendaten gerade nicht verfügbar'.

Tests 19/19 grün.

backend/routes/partner.py

@@ -93,21 +93,34 @@ def grant_user_status(user_id: int, data: GrantRequest, user=Depends(require_adm
         if not target:
             raise HTTPException(404, "User nicht gefunden.")
         if updates.get("is_founder") == 1 and not target["founder_number"]:
-            # Neue Gründer-Nummer zuweisen
-            total = conn.execute(
-                "SELECT COUNT(*) FROM users WHERE is_founder=1"
-            ).fetchone()[0]
-            if total >= FOUNDER_MAX:
+            # Atomare Gründer-Vergabe — kein TOCTOU mehr zwischen COUNT und UPDATE.
+            # Sub-Query wird gegen Snapshot vor dem UPDATE evaluiert (SQL-Spec).
+            cur = conn.execute(
+                """UPDATE users
+                      SET is_founder = 1,
+                          founder_number = (
+                            SELECT IFNULL(MAX(founder_number), 0) + 1
+                              FROM users WHERE is_founder = 1
+                          )
+                    WHERE id = ?
+                      AND (SELECT COUNT(*) FROM users WHERE is_founder = 1) < ?
+                      AND (is_founder IS NULL OR is_founder = 0)""",
+                (user_id, FOUNDER_MAX)
+            )
+            if cur.rowcount == 0:
                 raise HTTPException(400, f"Alle {FOUNDER_MAX} Gründer-Plätze sind vergeben.")
-            updates["founder_number"] = total + 1
+            # is_founder + founder_number sind atomar gesetzt — aus updates entfernen
+            updates.pop("is_founder", None)
+            updates.pop("founder_number", None)
         elif updates.get("is_founder") == 0:
             # Gründer-Status entfernen → founder_number ebenfalls leeren
             updates["founder_number"] = None
-        set_clause = ", ".join(f"{k}=?" for k in updates)
-        conn.execute(
-            f"UPDATE users SET {set_clause} WHERE id=?",
-            (*updates.values(), user_id)
-        )
+        if updates:                          # nach atomarer Founder-Vergabe ggf. leer
+            set_clause = ", ".join(f"{k}=?" for k in updates)
+            conn.execute(
+                f"UPDATE users SET {set_clause} WHERE id=?",
+                (*updates.values(), user_id)
+            )
         row = conn.execute(
             "SELECT id, name, email, is_founder, is_partner, founder_number FROM users WHERE id=?",
             (user_id,)