fix(webui): Ansichtsrettung suchte am falschen Ort, Suche findet Nummern

#288 war mit dem Transport allein nicht behoben. Die Ansichtsrettung fragte
dokumentweit nach der offenen Unteransicht:

    document.querySelector('.subtab-content.active')

Im Markup tragen aber ACHT Unteransichten diese Klasse - jedes Modul hat seine
eigene Startansicht, und switchMainTab() raeumt nur innerhalb des Moduls auf,
das es oeffnet. Zurueck kam deshalb immer die erste in Dokumentreihenfolge
(sub-projects-list), voellig unabhaengig davon, was gerade sichtbar war. Wer im
Bugtracker filterte, waere also auf der Projektverwaltung gelandet.

Dass die Rettung fuer POST-Formulare zu funktionieren schien, lag an den
wenigen, die ihren Anker fest in der action stehen haben. Gesucht wird jetzt
erst das aktive Modul und darin die Unteransicht.

Zusaetzlich tragen die drei Filterformulare das Feld "view" fest im Markup.
Dort ist ohne Zweifel bekannt, wo sie stehen - das haengt an keiner DOM-Abfrage
mehr. Und restoreViewFromHash() faellt bei einer unbekannten Unteransicht auf
das Modul zurueck, statt wortlos im Dashboard zu landen.

Nachgewiesen an einer DOM-Probe, die die Modulstruktur aus index.php nachbaut
und die echten Funktionen darauf laufen laesst: alte Fassung -> tab-projects,
neue Fassung -> sub-bugtracker-items.

Ausserdem, aus derselben Sitzung gemeldet: Die Suche findet Eintraege jetzt
ueber ihre Nummer. Sie ist das, was ueberall zitiert wird, und stand in keiner
der durchsuchten Spalten - "288" lief ins Leere. "288" findet jetzt das Item
mit dieser Nummer und alles, was die Zahl im Text hat; "#288" ausschliesslich
dieses eine. Gilt fuer Bugtracker, Fehler-Stream und den Parameter search der
API, der bei der Gelegenheit auch in die OpenAPI-Beschreibung gekommen ist.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

public/docs/changelog.json

@@ -43,13 +43,25 @@
           "area": "webui",
           "breaking": false,
           "title": "Filter und Formulare werfen nicht mehr aufs Dashboard zurueck",
-          "text": "Welche Ansicht sichtbar ist, hing allein am Anker der URL. Fuer POST-Formulare gab es dafuer laengst eine Loesung (_return und dc_redirect), die Filter fielen aber durch beide Netze: Es sind GET-Formulare, und ein GET-Formular verwirft beim Absenden den Anker seiner action; ausserdem loesten sie ueber form.submit() aus, was gar kein submit-Ereignis erzeugt. Nach jeder Filteraenderung stand man wieder im Dashboard und musste zurueckklicken - beim Filtern nach mehreren Parametern jedes Mal. Jetzt haengt der zentrale Zuhoerer die offene Ansicht bei GET als Parameter 'view' an den Query-String, ausgeloest wird ueber requestSubmit(), und beim Laden wird die Ansicht aus 'view' wiederhergestellt, wenn kein Anker da ist."
+          "text": "Welche Ansicht sichtbar ist, hing allein am Anker der URL - und die Ansichtsrettung, die das auffangen sollte, griff aus zwei Gruenden nicht.\n\nErstens fragte sie dokumentweit nach der offenen Unteransicht. Im Markup tragen aber ACHT Unteransichten die Klasse \"active\": jedes Modul hat seine eigene Startansicht, und switchMainTab() raeumt nur innerhalb des Moduls auf, das es oeffnet. Zurueck kam deshalb immer die erste in Dokumentreihenfolge, unabhaengig davon, was gerade sichtbar war. Dass die Rettung trotzdem zu funktionieren schien, lag an den wenigen Formularen, die ihren Anker fest in der action stehen haben. Gesucht wird jetzt erst das aktive Modul und darin die Unteransicht.\n\nZweitens fielen die Filter durch das Netz: Es sind GET-Formulare, und ein GET-Formular verwirft beim Absenden den Anker seiner action; ausserdem loesten sie ueber form.submit() aus, was gar kein submit-Ereignis erzeugt. Der zentrale Zuhoerer haengt die offene Ansicht bei GET jetzt als Parameter \"view\" an den Query-String, ausgeloest wird ueber requestSubmit(), und beim Laden wird die Ansicht daraus wiederhergestellt. Die drei Filterformulare tragen das Feld zusaetzlich fest im Markup - dort ist ohne Zweifel bekannt, wo sie stehen, und das haengt an keiner DOM-Abfrage mehr."
         },
         {
           "area": "api",
           "breaking": false,
           "title": "/api/bugtracker/v1/roadmap ist jetzt auch ohne .php erreichbar",
           "text": "Jeder andere Endpunkt kommt ohne Dateiendung aus, dieser nicht: Die Route fehlte in der .htaccess, der Aufruf lief in ein 404, und die OpenAPI-Beschreibung fuehrte deshalb als einzigen Pfad einen mit .php. Wer dem Muster der uebrigen API folgte, lief auf. Die Route ist nachgetragen, die Beschreibung nennt jetzt den Pfad ohne Endung. Der alte Pfad mit .php funktioniert unveraendert weiter - er faellt auf die allgemeine Regel fuer /api/ zurueck."
+        },
+        {
+          "area": "webui",
+          "breaking": false,
+          "title": "Die Suche findet Eintraege ueber ihre Nummer",
+          "text": "Die Nummer ist das, was ueberall zitiert wird - in Commits, in Kommentaren, im Changelog - und war ausgerechnet ueber die Suche nicht auffindbar: Sie steht in keiner der durchsuchten Spalten. Wer \"288\" eingab, bekam nichts und musste die Liste durchblaettern. Jetzt sucht die Nummer mit, im Bugtracker wie im Fehler-Stream und ebenso ueber den Parameter search der API. Zwei Schreibweisen, zwei Bedeutungen: \"288\" findet das Item mit dieser Nummer UND alles, was die Zahl im Text stehen hat; \"#288\" ist eindeutig gemeint und liefert ausschliesslich dieses eine Item."
+        },
+        {
+          "area": "api",
+          "breaking": false,
+          "title": "Der Parameter search ist jetzt beschrieben",
+          "text": "action=list kennt search seit jeher, in der OpenAPI-Beschreibung stand er nicht. Nachgetragen, mitsamt dem Verhalten bei Zahlen."
         }
       ]
     },