feat: optimize search.php for the mobile view

search.php had no mobile treatment: the query form rendered as an
unstyled desktop table, and a submitted search fell back to the regular
forum-listing view on the untested assumption that results looked like
topic rows.

The query form is now recognised by its forum-picker select, the one
element the small "search this forum/topic" widgets embedded on other
pages don't share — they reuse the same form action and keyword field
name and would otherwise be picked up by mistake. Results in the "Posts"
display mode the in-thread search bar produces turned out to carry post
excerpts, not topic rows, and needed their own card layout instead of
running through the list view, which would have misread the topic and
profile links inside each hit.

Submit/reset controls kept native iOS Safari chrome even under
-webkit-appearance:none once restyled, clipping their labels — only
visible on device, not in the emulator this project is developed
against. Replacing them with real <button> elements (same name/value,
so the submitted form data is unchanged) fixed it where the CSS-only
attempt didn't; touch targets were sized up to match.

CLAUDE.md

@@ -13,6 +13,8 @@ die `.user.js`-Datei ist das Produkt.
 | `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 |
+| `dev/search.php` | — | Fixture: Suchformular ohne Treffer, eingeloggt aufgenommen |
+| `dev/search2.php` | — | Fixture: Suchtreffer im Modus "Posts" (15 von 1438 Treffern, `t=63042`, `per_page=15`, 96 Seiten) |
 
 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
@@ -203,6 +205,90 @@ Original-Zurueck/Weiter-Links, das Sheet verschwindet.
 einer verschachtelten Tabelle, `closest('tr')` trifft die innere Zeile ohne
 Autor- und Profilspalte.
 
+**Die Lupe und die Login-Pille haengen an einer gemeinsamen `margin-left:auto`
+auf einem Wrapper (`.rm-auth-group`), nicht je an sich selbst.** Saesse die
+Regel wie zuvor direkt auf `.rm-auth`, wuerde nur die Pille an den Rand
+geschoben und die Lupe bliebe links davon kleben — mit sichtbarer Luecke
+dazwischen statt „direkt links neben der Pille". Die Lupe existiert im Markup
+ohnehin nur bei bestehender Sitzung; ausgeloggt bleibt der Wrapper mit der
+Pille als einzigem Kind und verhaelt sich exakt wie vorher.
+
+**`#topic-search` steht dreifach identisch im Thread-Markup** (Kopf, Fuss,
+ueber der Beitragsliste), jedes Mal mit derselben, eigentlich unzulaessigen
+`id`. `document.querySelector('#topic-search')` trifft einfach das erste und
+verschiebt es unveraendert in die zweite Leiste — alle drei tragen dieselben
+versteckten Felder (`t`, `sf`, `terms`), welches der drei benutzt wird, ist
+gleichgueltig.
+
+**`select[name="fid[]"]` ist der einzige verlaessliche Marker fuer das grosse
+Suchformular auf `search.php`.** Sowohl `viewforum.php` als auch
+`viewtopic.php` betten ein eigenes Mini-Suchformular ein (`#forum-search` /
+`#topic-search`, „Search this forum…" / „Search this topic…"), beide mit
+`action="./search.php"` und einem Feld `name="keywords"` — nach diesen Merkmalen
+allein liesse sich das grosse Formular nicht von den kleinen unterscheiden.
+Der mehrfach waehlbare Forenwaehler existiert dagegen nur im grossen Formular.
+
+**Die Textfelder des Suchformulars tragen `style="width: 300px"` direkt im
+Markup.** Eine externe Regel ohne `!important` sticht dagegen nicht, egal wie
+spezifisch der Selektor ist — `buildSearchForm()` entfernt das
+`style`-Attribut deshalb, statt gegen es anzuschreiben.
+
+**Eine abgeschickte Suche liefert keine Themenliste, sondern einen ganz
+anderen Aufbau.** Die anfaengliche Annahme, Trefferzeilen tragen dieselben
+`topictitle`-Links wie eine Themenliste und laufen unveraendert durch
+`buildList()`, stimmte nicht — zumindest nicht im Modus "Posts" (`sr=posts`),
+der ueber die zweite Leiste im Thread entsteht, weil deren Formular kein `sr`
+setzt. Jeder Treffer ist stattdessen ein Beitragsauszug: Autor, Zeitstempel,
+Forum/Thema-Kontext, ein Stueck `postbody`. `buildSearchResults()` erkennt
+diesen Modus an `p.topictitle` — als `<p>`, nicht als `<a>` wie das
+gleichnamige Klassenpendant einer Themenzeile in `viewforum.php` — und baut
+daraus eigene Karten (`buildHit()`), bevor `buildList()`s allgemeines
+Zeileneinsammeln ueberhaupt anfaengt und die enthaltenen `viewtopic.php`-Links
+falsch klassifizieren wuerde. Ungeprueft bleibt der Modus "Topics" (`sr=topics`,
+Vorauswahl im grossen Suchformular) — dafuer liegt keine Fixture vor, dort
+sehen Treffer laut phpBB-Doku tatsaechlich wie topictitle-Zeilen aus und
+wuerden vermutlich durch den regulaeren Listenzweig laufen, das ist aber nicht
+verifiziert.
+
+**Ein Treffer im Modus "Posts" besteht aus drei `<tr>`, unterscheidbar nur an
+der Position, nicht an einer Klasse.** Titelzeile (`p.topictitle`), Autor-
+und Betreffzeile, dann Antworten/Views samt Beitragsauszug — alle drei
+tragen row1/row2 wahllos, die einzige verlaessliche Zuordnung ist
+`nextElementSibling` von der Titelzeile aus.
+
+**Der Beitragsauszug haengt in `<td class="postbody">`, nicht in
+`div`/`span.postbody` wie im echten Thread.** `buildHit()` verschiebt das
+`<td>` trotzdem unveraendert per `appendChild()` in `.rm-body` — das ist reine
+DOM-Manipulation, keine Neuparse, darum meckert der Browser nicht ueber ein
+`<td>` ausserhalb einer Tabelle. Es rendert danach aber weiterhin als
+`display:table-cell`, wenn `.rm-root.rm-hits .rm-body > td` das nicht
+ausdruecklich auf `block` zwingt.
+
+**"Replies: 5403" und "Views: 951837" stehen im Markup nur durch ein `<br />`
+getrennt, ohne Leerzeichen.** `txt()` normalisiert Whitespace, erzeugt aber
+keinen wo im Original-Markup keiner steht — `txt(meta)` liefert deshalb
+`5403Views:951837` statt zwei getrennter Werte. `buildHit()` greift beide
+Zahlen einzeln per Regex heraus und reicht sie an dieselbe `metaRow()` wie bei
+Themenkarten weiter, die den Trenner per CSS (`::before`) selbst einfuegt.
+
+**`input[type="submit"]`/`input[type="reset"]` setzen eigenes Padding und
+Zentrierung in iOS Safari unzuverlaessig um — auch mit `-webkit-appearance:
+none`.** Zuerst aufgefallen bei Suchen/Zuruecksetzen im Suchformular
+nebeneinander, wo die feste Flex-Aufteilung die Verzerrung besonders sichtbar
+machte: zu schmale Buttons, Text nicht mittig. `-webkit-appearance:none` plus
+`box-sizing:border-box`/`line-height:normal` (erster Versuch) reichte laut
+Test am Geraet nicht aus — das legt einen tieferen WebKit-Bug nahe, bei dem
+`input[type=submit/reset]` die native Knopfoptik trotz `appearance:none` nicht
+vollstaendig ablegt. Der tragfaehige Fix ist `inputToButton()`: die
+Original-`<input>`-Elemente werden vor dem Verschieben durch echte
+`<button type="submit/reset">` ersetzt (Name und Value wandern mit, am
+uebermittelten Formularfeld aendert sich nichts) — `<button>` wird von WebKit
+unter `appearance:none` zuverlaessig respektiert. Betrifft grundsaetzlich
+jeden Submit-Button im Script: Suchformular, Login, Thread-Suchleiste nutzen
+alle `inputToButton()`. Ungeprueft, ob `-webkit-appearance:none` allein bei
+einer anderen iOS-Version genuegt haette — der Wechsel auf `<button>` umgeht
+die Frage, statt sie zu beantworten.
+
 **`DEBUG` steht auf `true`** und muss vor dem Ausliefern auf `false`. Die
 Versionsnummer steht doppelt: im `@version`-Header und im Text des
 Debug-Overlays.
@@ -267,6 +353,27 @@ 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.
 
+Fuer das Suchformular genuegt `dev/search.php` unveraendert, URL
+`search.php`: geprueft werden der Forenwaehler als Erkennungsmerkmal, das
+verschobene Formular samt versteckter Felder (`t`, `sid`), die entfernten
+inline-`style`-Attribute der Textfelder und die Schnellzugriffs-Chips aus
+`p.searchbar`. Zu pruefen ist ausserdem `dev/viewforum.php` auf derselben
+Weiche: dessen eingebettetes `#forum-search`-Mini-Formular teilt sich Aktion
+und `keywords`-Feld mit dem grossen Suchformular und darf `buildSearchForm()`
+nicht faelschlich auslösen, die Forenliste muss wie gewohnt Karten liefern.
+
+Fuer Suchtreffer genuegt `dev/search2.php` unveraendert, URL beliebig (die
+Erkennung haengt nicht an `location`, sondern an `p.topictitle` im Markup):
+geprueft werden alle 15 Trefferkarten, die verschobene "Searched topic /
+Search term used"-Zelle samt ihrer beiden Links, Autor und Zeitstempel pro
+Treffer, die per Regex getrennten Antworten-/Views-Zahlen, der verschobene
+`td.postbody`-Beitragsauszug und die Seitennavigation (`per_page=15`, 96
+Seiten). Zu pruefen ist ausserdem, dass `dev/search.php` (das leere Formular)
+weiterhin den Formular-Zweig trifft und nicht in die Treffer-Erkennung faellt,
+und dass `dev/viewforum.php` weiterhin normale Karten liefert — beide haben
+kein `p.topictitle`. Der Modus "Topics" (`sr=topics`) ist mangels Fixture
+ungeprueft.
+
 Am Geraet zu pruefen bleibt, was Blink nicht zeigt: `env(safe-area-inset-*)`,
 fixierte Leisten gegen Safaris ein- und ausfahrende Toolbar,
 `-webkit-backdrop-filter`, Schriftskalierung. Details und die