feat: rebuild the forum index and post-login pages into the mobile view

The list view already handled every table row shape a forum page uses,
but the switch only ever routed viewforum.php and search.php into it;
index.php arrived untouched, so the very first page a visitor lands on
stayed in the desktop layout. It matches the same category/forum row
structure a viewforum.php category page already produces, so no new
building logic was needed, only the routing.

Submitting the login form reveals a second gap: it re-renders the same
URL with a generic confirmation page instead of the form, which the
existing form-lookup silently ignored, leaving that page unstyled too
right before phpBB's own redirect fires. It shares its shape with any
other message phpBB might render there (a wrong password, for example),
so the fix recognises it structurally rather than by its wording, and
carries the original message cell over unchanged the same way the login
form itself is reused rather than rebuilt.

CLAUDE.md

@@ -10,7 +10,9 @@ die `.user.js`-Datei ist das Produkt.
 | `dev/rin-mobile.dev.user.js` | zusaetzlich `localhost:*` | Loader, bindet per `@require file:///` das echte Script ein |
 | `dev/viewtopic.php` | — | Fixture: gespeicherter Thread, 1114 Seiten |
 | `dev/viewforum.php` | — | Fixture: Main Forum, 610 Seiten, mit Unterforen, Ankuendigungen und Stickies |
+| `dev/index.php` | — | Fixture: Forumwurzel, zwei Kategorien mit Forenzeilen, keine Paginierung |
 | `dev/ucp.php` | — | Fixture: Login-Formular (`mode=login`), nur ausgeloggter Zustand |
+| `dev/after_login/ucp.php` | — | Fixture: dieselbe URL nach erfolgreichem Login, "Information"-Vorlage statt Formular |
 
 Die Fixtures sind ueber `.gitignore` (`dev/*.php`) ausgeschlossen. Nach einem
 frischen Klon sind sie nicht da und muessen nach der Anleitung in der README neu
@@ -115,13 +117,31 @@ klammert das `overflow` dagegen nicht, weil der Root keinen Containing Block
 aufspannt. Die Freihaltung oben haengt an `body.rm-crumbed`, damit ohne
 Brotkrumen im Markup kein leerer Streifen bleibt.
 
-**Die Login-Erkennung ist ungetestet gegen eine echte Sitzung.** `loginState()`
-unterscheidet `a[href*="mode=login"]` von `a[href*="mode=logout"]` im
-Menuebalken und liest den Namen aus dem vermuteten Muster `Logout [ Name ]` im
-Linktext. Dem Repository liegt keine eingeloggte Fixture vor — passt das
-Namensmuster nicht, bleibt die Pille bei „Logout" ohne Namen stehen, statt eine
-Ausnahme zu werfen. Vor einer Aenderung an `loginState()` erst mit einer echten
-Sitzung pruefen, wie die Zeile tatsaechlich aussieht.
+**Die Login-Erkennung ist inzwischen gegen eine echte Sitzung geprueft.**
+`loginState()` unterscheidet `a[href*="mode=login"]` von
+`a[href*="mode=logout"]` im Menuebalken und liest den Namen aus dem Muster
+`Logout [ Name ]` im Linktext. `dev/index.php` und `dev/after_login/ucp.php`
+sind eingeloggt aufgenommen (`Logout [ <Benutzername> ]`) und bestaetigen das Muster.
+Der Fallback bleibt trotzdem stehen: passt das Muster einmal nicht — andere
+Sprache, anderer Klammertyp — zeigt die Pille „Logout" ohne Namen, statt eine
+Ausnahme zu werfen.
+
+**`ucp.php?mode=login` rendert nach dem Absenden dieselbe URL neu, diesmal
+ohne Formular.** phpBB fuellt die Zwischenmeldung („You have been successfully
+logged in.") in dieselbe generische „Information"-Vorlage, die auch fuer
+andere Meldungen auf dieser Seite dient (vermutlich auch Login-Fehler, dafuer
+liegt aber keine Fixture vor). `buildLoginInfo()` erkennt die Vorlage deshalb
+an ihrer Form — eine Kopfzeile mit genau einer `th`-Zelle, gefolgt von einer
+`td.row1`-Nachrichtenzelle — nicht am Wortlaut, und uebernimmt die Zelle
+unveraendert wie das Formular selbst. Findet `buildLogin()` weder Formular
+noch diese Form, baut es nichts; die Originalseite bleibt sichtbar.
+
+**`index.php` wird ueber `location.pathname` erkannt, nicht ueber
+`here`.** Der Login-Redirect haengt "index.php" gelegentlich als Wert eines
+Query-Parameters an `ucp.php` (`redirect=index.php`, siehe `dev/ucp.php`).
+Ein Test auf `location.pathname + location.search` wie bei den uebrigen
+Weichen wuerde eine solche Login-URL faelschlich als Liste einordnen, noch
+bevor die Pruefung auf `ucp.php` ueberhaupt greift.
 
 **Ist eine Seite nicht laenger als der Viewport, kann Safari nicht wegscrollen,
 um seine eigene Werkzeugleiste unten freizugeben.** Bei Liste und Thread faellt
@@ -217,11 +237,20 @@ die Zahlenspalten dasselbe Ergebnis liefern.
 
 Fuer den Login genuegt `dev/ucp.php` unveraendert: geprueft werden das
 uebernommene Formular (Username-/Passwortfeld, `sid`, `redirect`, Submit) und
-die Pille in beiden Zustaenden — Letzteres per Textersetzung von
-`mode=login` zu `mode=logout&sid=…Logout [ Name ]…` in der eingelesenen
-Fixture, da eine echte eingeloggte Seite fehlt. Das Namensmuster bleibt damit
-nur gegen die eigene Annahme getestet, nicht gegen echtes Markup — siehe die
-Falle oben.
+die Pille im ausgeloggten Zustand. Fuer den eingeloggten Zustand der Pille
+`dev/index.php` oder `dev/after_login/ucp.php` laden — beide sind eingeloggt
+aufgenommen und tragen das echte `Logout [ Name ]`-Markup.
+
+Fuer die Meldung nach dem Login genuegt `dev/after_login/ucp.php`
+unveraendert, URL `ucp.php?mode=login`: geprueft werden Titel, uebernommene
+Nachricht samt Link und die Pille. Zu pruefen ist ausserdem, dass `dev/ucp.php`
+(das Formular, gleiche URL) weiterhin die Formular-Zweig traf und nicht in die
+Meldungs-Erkennung faellt.
+
+Fuer die Forumwurzel genuegt `dev/index.php`, URL `index.php?sid=…`: zwei
+Kategorien mit zusammen 16 Forenkarten, keine Paginierung. Zu pruefen ist
+zusaetzlich eine `ucp.php?mode=login&redirect=index.php`-URL — sie muss trotz
+des `index.php`-Substrings im Login-Zweig landen, nicht im Listen-Zweig.
 
 Am Geraet zu pruefen bleibt, was Blink nicht zeigt: `env(safe-area-inset-*)`,
 fixierte Leisten gegen Safaris ein- und ausfahrende Toolbar,