Upgrader UI Anpassungen

[Avatarsia]

Motivation / Problem
Die bisherige Upgrade-Seite machte es schwer zu erkennen:

ob ein Check erfolgreich war oder fehlgeschlagen ist,
ob ein Update verfügbar ist oder alles aktuell ist,
welcher Stand lokal läuft vs. welcher Stand als Upgrade-Ziel konfiguriert ist,
welche nächste Aktion sinnvoll ist (prüfen vs. aktualisieren),
warum ein Upgrade blockiert (z.B. geänderte Dateien) und was zu tun ist.
Was wurde umgesetzt?

1. Neues Layout / UX (deutsch, modern)
   Deutlich sichtbarer Status-Bereich (Status-Banner) mit verständlicher Kurzbeschreibung.
   Prozess in zwei klar getrennten Kacheln:
   Dateien / Code & Repo (prüfen/starten, Force-Option)
   Datenbank / DB-Check & Upgrade
   Protokoll weiterhin vorhanden, mit größerem Abstand nach oben für bessere Lesbarkeit.

2. Versionsabgleich: verständlich für Laien
   Der Versionsabgleich orientiert sich nicht mehr an „Branch-Namen“, sondern am tatsächlichen Git-Commit:

OpenXE-Version (bereinigt aus der Revision-Anzeige, ohne verwirrende Hash-/Branch-Zusätze)
Code-Stand (Git): lokaler HEAD-Commit (kurz) + Datum
Upgrade-Quelle: Remote-URL + Branch + Remote-HEAD-Commit (kurz)
Status als farbige Pill:
„Alles aktuell“ wenn lokaler Commit == Remote-Commit
„Update verfügbar“ wenn abweichend
„Remote nicht erreichbar“ etc. bei Problemen
Zusätzlich: Der lokale Branch-Name wird in der „Code-Stand (Git)“-Zeile nur dann gezeigt, wenn er dem Branch der Upgrade-Quelle entspricht – damit master/main nicht verwirrend angezeigt wird, wenn die Upgrade-Quelle auf einen anders benannten Branch zeigt.

3. Upgrade-Quelle im UI steuerbar + Reset-Fallback
   Remote-URL und Branch können weiterhin im UI gesetzt und in upgrade/data/remote.json gespeichert werden.
   One-Click Reset: „Quelle auf Original zurücksetzen“ stellt die Upgrade-Quelle wieder auf die beim Speichern hinterlegten Originalwerte zurück (original_host / original_branch).
   Dadurch ist ein schnelles Zurücksetzen auf „Standard“ ohne manuelle Dateibearbeitung möglich.
4. Fehlerfall „lokale Änderungen“ besser geführt
   Wenn im Protokoll erscheint, dass lokale Änderungen den Prozess blockieren (Clear modified files or use -f):

wird die Option „Erzwingen (-f)“ automatisch sichtbar gemacht,
visuell markiert (Highlight-Rahmen + Hintergrund),
Status/GUIDANCE geben eine klare Anweisung, dass -f genutzt oder lokale Änderungen bereinigt werden müssen.

5. Standardmäßig Details aktiv
   Detailausgaben sind standardmäßig aktiv, ohne dass der User jedes Mal Checkboxen setzen muss.
   Technische Details / betroffene Dateien
   www/pages/upgrade.php

Status-/Guidance-Logik erweitert
Remote-Quelle speichern + Originalwerte persistieren
One-Click Reset auf Originalquelle
Git-Stand ermitteln: lokaler HEAD vs. Remote HEAD (git ls-remote)
Force-Highlight bei „modified files“-Fehler
bessere Template-Variablen (APP_VERSION, LOCAL_HASH_SHORT, REMOTE_HASH_SHORT, UPDATE_STATUS*, LOCAL_BRANCH_VISIBLE, FORCE_HIGHLIGHT_CLASS)
www/pages/content/upgrade.tpl

Neues Layout (Banner + Step-Kacheln)
Versionsabgleich-Karte angepasst (laienfreundliche Begriffe)
Protokoll-Abstand erhöht (.log-section { margin-top: 50px; })
Force-Highlight Styling
upgrader-ui-changelog.md

Changelog/Notizen zur Umsetzung (Gedächtnisstütze)
Verhalten / Testing-Hinweise

Upgrade-Seite öffnen → Status/Stepper sichtbar
„Upgrades prüfen“ / „DB prüfen“ → Protokoll füllt sich, Status/Guidance aktualisieren
remote.json im UI ändern + speichern → Versionsabgleich nutzt neue Quelle
„Quelle auf Original zurücksetzen“ → remote.json springt auf gespeicherte Originalwerte zurück
Fehlerfall „modified files“ reproduzieren → Force-Checkbox erscheint und wird hervorgehoben

Screens / Erwartetes Ergebnis
Klare Aussage: „Alles aktuell“ vs. „Update verfügbar“
Klare nächste Schritte (prüfen → starten)
„Erzwingen (-f)“ wird nur dann prominent, wenn es wirklich relevant ist
Keine manuelle Bearbeitung von remote.json nötig, inklusive Reset-Option