feat: Anmelden mit Passkey

Passkeys (WebAuthn/FIDO2) als zweiter Anmeldeweg - auf der Anmeldeseite
und bei der erneuten Bestaetigung vor sensiblen Aktionen. Verwaltet unter
"Mein Konto".

Der Passkey ERSETZT den zweiten Faktor, statt zu ihm hinzuzukommen. Das
ist tragbar, weil er zwei Faktoren in sich vereint: Besitz des Geraets
und dessen Entsperrung. Damit das keine Annahme bleibt, wird die
Nutzerverifikation angefordert (userVerification: 'required') und
serverseitig nachgeprueft - eine Antwort ohne sie wird abgewiesen.

TOTP muss vorher eingerichtet sein. Ein Passkey haengt an einem Geraet;
waere er der einzige Weg hinein, koennte ein verlorenes Handy die Akte
schliessen.

Aufbau:
- Die Pruefung laeuft vollstaendig im Credentials-Provider "passkey",
  nicht in der Server Action davor. Ein "war schon geprueft" ueber die
  Grenze zu reichen waere die Stelle, an der sich Anmeldungen faelschen
  lassen.
- Challenges liegen serverseitig und werden per DELETE genau einmal
  verbraucht - die Datenbank entscheidet, wer sie bekommt.
- Bereichskennung und Herkunft kommen aus AUTH_URL, nicht aus einer
  zweiten Konfigurationsquelle.
- Ohne https wird der Knopf gar nicht erst angeboten.
- Rate-Limiting, Kontosperre und Audit-Log gelten unveraendert; die
  Anmeldung nennt den verwendeten Passkey namentlich.

Zwei Anmerkungen zur Migration:
- "prisma migrate diff" wollte zusaetzlich die Trigramm-Indizes aus
  prisma/sql/suche.sql loeschen, die Prisma nicht kennt. Die Zeilen sind
  entfernt und im Migrationskopf vermerkt - ein DROP haette die unscharfe
  Suche stillgelegt, ohne dass etwas fehlgeschlagen waere.
- "prisma format" hat das Schema durchgaengig neu ausgerichtet. Ohne
  Whitespace betrachtet sind es 88 hinzugefuegte Zeilen und keine
  geloeschte.

Geprueft: 21 Einheitstests, drei End-to-End-Tests gegen Chromiums
virtuellen Authenticator (einrichten, anmelden, bestaetigen, entfernen,
Geraet ohne Verifikation abgewiesen), beide Geraeteprofile. 496 Tests,
null Typfehler, Produktionsbau steht.

Nebenbei: Die Zahlen im README waren veraltet (24 statt 33 Modelle, 46
statt 79 Seiten). Sie stehen jetzt mit dem Befehl daneben, mit dem man
sie nachzaehlt.

docs/ROADMAP.md

@@ -9,7 +9,7 @@ Zeit spart. Er steht weit unten, wenn er nur schön wäre.
 Diese Datei ist eine Absichtserklärung, kein Vertrag. Was sich im Betrieb
 als wichtiger herausstellt, rutscht nach oben.
 
-Stand: 22.08.2026 · Aktuelle Fassung: **1.0.0** ([CHANGELOG](../CHANGELOG.md))
+Stand: 22.08.2026 · Aktuelle Fassung: **1.1.0** ([CHANGELOG](../CHANGELOG.md))
 
 ---
 
@@ -136,6 +136,31 @@ Jahresbericht und bei einer Höherstufung gebraucht.
 
 ---
 
+## 1.2b — Passkeys abrunden
+
+Der Grundstock steht seit 1.1.0. Was noch fehlt, ist Bequemlichkeit, nicht
+Sicherheit.
+
+### Passkey direkt im Anmeldefeld anbieten
+
+Browser können einen Passkey im Ausfüllvorschlag des E-Mail-Feldes
+anbieten (*conditional UI*), statt hinter einem eigenen Knopf. Ein Schritt
+weniger. Braucht einen zweiten Challenge-Weg und sorgfältiges Abbrechen,
+wenn stattdessen doch das Passwort getippt wird.
+
+### Passkey umbenennen
+
+Heute geht nur anlegen und entfernen. Wer sein Gerät „Handy" genannt hat
+und inzwischen zwei hat, muss den Passkey neu einrichten.
+
+### Warnen, wenn der letzte Passkey nur auf einem Gerät liegt
+
+Die Liste sagt bereits, ob ein Schlüssel gesichert ist. Wer ausschließlich
+ungesicherte Passkeys hat und dazu keine Wiederherstellungscodes mehr,
+sollte das deutlicher zu sehen bekommen als in einer Zeile Kleingedrucktem.
+
+---
+
 ## 1.3 — Belastbarkeit
 
 **Ziel:** Die Stellen absichern, die bisher nur unter Laborbedingungen
@@ -164,6 +189,14 @@ Monat automatisch durchspielt — Sicherung zurückspielen, Diagnosen im
 Klartext prüfen, Testdatenbank verwerfen — wäre der Beweis statt der
 Absichtserklärung.
 
+### Passkey-Ablehnung ohne Browser nachstellen
+
+Die Prüfung „Passkey ohne Nutzerverifikation wird abgewiesen" ist im Code
+doppelt abgesichert und im Browsertest belegt — dort weist allerdings
+schon der Browser ab, der Server kommt gar nicht dran. Ein Test, der die
+Antwort von Hand baut und den Browser umgeht, würde den serverseitigen
+Rückhalt tatsächlich beweisen.
+
 ### Barrierefreiheits-Durchgang mit einem Screenreader
 
 Semantik, Fokusreihenfolge und Kontraste sind beim Bauen beachtet und in